Bitcoin Forum
August 17, 2018, 08:21:24 AM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions  (Read 11230 times)
Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000


View Profile
January 27, 2013, 12:15:30 AM
 #61

Yup, that's another known attack. bitcoinj is going to support recursive analysis of transaction depth IIRC, so you'd be able to say "don't accept chains more than x long"

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1534494084
Hero Member
*
Offline Offline

Posts: 1534494084

View Profile Personal Message (Offline)

Ignore
1534494084
Reply with quote  #2

1534494084
Report to moderator
1534494084
Hero Member
*
Offline Offline

Posts: 1534494084

View Profile Personal Message (Offline)

Ignore
1534494084
Reply with quote  #2

1534494084
Report to moderator
1534494084
Hero Member
*
Offline Offline

Posts: 1534494084

View Profile Personal Message (Offline)

Ignore
1534494084
Reply with quote  #2

1534494084
Report to moderator
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1005


View Profile
January 28, 2013, 10:18:07 AM
 #62

Do you know the miner who mined the double spends?

Although playing games with the consensus protocol will always be possible, the difficulty of executing such attacks can be made much harder through some simple community policing work to ensure that legitimate miners don't accidentally get co-opted into creating double spends.
jgarzik
Legendary
*
Offline Offline

Activity: 1554
Merit: 1001


View Profile
February 04, 2013, 04:18:31 PM
 #63

well... duh?

Who would have thought it was a good idea to consider a transaction complete if a guy claims to have sent you funds but they haven't actually been verified as legit by ANYONE yet?

In general...  agreed, with this sentiment and the opinions others have expressed in this thread.

However, it should be noted that certain situations may benefit from a mixed approach.  If you are a merchant shipping a physical product, the purchase process might look like
  • Request payment
  • User sends bitcoins
  • "Payment received!"
  • Hours or days pass, while product is packed and prepped for shipment
  • Order validation: Check and make sure bitcoins have not been double-spent
  • Ship product

So it is really product/situation dependent.  A situation like bitcoin exchange or SatoshiDICE would seem like the ideal example of when to not accept zero-conf transactions; alternately BitcoinStore.com would seem like an excellent example of what could follow the multi-step order flow above.

Multi-step Zero-conf-now-check-later gives the best user experience: fast immediately confirmation of funds receipt, with the security of multiple confirmations before final product delivery/enablement.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
pointbiz
Sr. Member
****
Offline Offline

Activity: 433
Merit: 252

1ninja


View Profile
February 10, 2013, 03:55:17 PM
 #64

Can someone now disclose the issue as promised? .... retep?

It appears to me that Mike Hearn has had the correct non-panicky level headed approach to this. Can someone explain how this is an exploit as opposed to expected functional behavior? It took me a lot of reading to determine this is a non issue?!? Am I wrong?

Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Satoshi's wait 10 seconds for unconfirmed transactions to listen for a double spend applies to transactions that can feasibly make it to a block. Not for ones with lock times decades in the future?!?

 It also seems like no miner made the wrong choose for greed rather they took a committed transaction and put it in a block instead of its uncommitted locked version? Again am I wrong?

Coder of: https://www.bitaddress.org      Thread
Open Source JavaScript Client-Side Bitcoin Wallet Generator
Donations: 1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN   PGP
Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000


View Profile
February 11, 2013, 05:37:29 AM
 #65

Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Transaction replacement is currently disabled. Multiple parties discussed this issue extensively, and the consensus was that the minor utility of being able to broadcast non-final transactions was not important enough given the drawbacks.

True transaction replacement probably needs to be done as a separate P2P layer, and in any case always has the problem that there is nothing stopping miners from mining older versions of the transaction that they know about.

Satoshi's wait 10 seconds for unconfirmed transactions to listen for a double spend applies to transactions that can feasibly make it to a block. Not for ones with lock times decades in the future?!?

That's the main reason this was considered a serious issue: code was doing exactly that and not taking into account that transactions can be made invalid until thousands of years in the future. (Maximum nLockTime setting locks the transaction until July 18, 11515) There are lots of UI's that make no distinction between transactions that can be mined now and ones that can't. The same applied to services; I did after all steal 5BTC from blockchain.info exploiting this oversight.

It also seems like no miner made the wrong choose for greed rather they took a committed transaction and put it in a block instead of its uncommitted locked version? Again am I wrong?

A non-final transaction can not be included in a block until it finalizes and thus miners have nothing to do with the issue.

caveden
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000



View Profile
February 11, 2013, 08:19:27 AM
 #66

Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Transaction replacement is currently disabled. Multiple parties discussed this issue extensively, and the consensus was that the minor utility of being able to broadcast non-final transactions was not important enough given the drawbacks.

That's what I feared. You're seriously killing nLockTime for good?

Such feature can be really useful. Think inheritance for instance. How would you implement inheritance in a "bank" which uses multi-signature? You die, all your money dies with you?
Even for password regeneration... suppose you run a multisig bank in BTC, and you don't really trust all your clients to never forget their passwords (people do often forget/lose their passwords, and I bet that in some jurisdictions you would be forced to give your client a way to retrieve their money even if he forgot his password). Using nLockTime would be just great for this. You periodically transfer the money to a cold storage address the bank fully controls. While the client is logging in, you periodically reverse that transaction and generates a new one. If your client ever forgets his password for good, you'd just need to positively identify him (docs etc) and ask him to wait like 3 months or something to have his coins back.

Anyways. This is a powerful feature. The fact that's not yet exploited doesn't mean otherwise: multisig itself is not really exploited so far, and I don't think you'd say that feature is "not important enough".

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Luke-Jr
Legendary
*
Offline Offline

Activity: 2408
Merit: 1001



View Profile
February 11, 2013, 09:04:34 AM
 #67

nLockTime isn't killed "for good", it's just considered non-standard so the default client won't relay or pay attention to it. Since the client already doesn't support replacement, this really is pretty harmless. A future client that does support replacement can add it back in after another conversation.

Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000


View Profile
February 11, 2013, 09:27:47 AM
 #68

nLockTime isn't killed "for good", it's just considered non-standard so the default client won't relay or pay attention to it. Since the client already doesn't support replacement, this really is pretty harmless. A future client that does support replacement can add it back in after another conversation.

Specifically nLockTime is only considered non-standard when the transaction is not final yet. That is the locktime hasn't been reached, and the transaction is not eligible to be included in a block. Non-standard just means that nodes won't relay such transactions on the P2P network, but nothing stops you from saving the transaction yourself and broadcasting it when the locktime is reached and the transaction finalizes.

Such feature can be really useful. Think inheritance for instance. How would you implement inheritance in a "bank" which uses multi-signature? You die, all your money dies with you?
Even for password regeneration... suppose you run a multisig bank in BTC, and you don't really trust all your clients to never forget their passwords (people do often forget/lose their passwords, and I bet that in some jurisdictions you would be forced to give your client a way to retrieve their money even if he forgot his password). Using nLockTime would be just great for this. You periodically transfer the money to a cold storage address the bank fully controls. While the client is logging in, you periodically reverse that transaction and generates a new one. If your client ever forgets his password for good, you'd just need to positively identify him (docs etc) and ask him to wait like 3 months or something to have his coins back.

You can do that just fine even if non-final transactions are not-standard. Just create the transactions that send the money back to the client, set the nLockTime so that they will not be valid for 3 months, and then sign them. You can freely give the client copies of these transactions. As the three months approaches, move the coins to invalidate the txin's of the previous set of locked transactions and create new refund transactions. If the refund transactions are ever needed, just wait until they have finalized, and broadcast them on the P2P network as you would any other transaction.

Ultimately the thing is transaction replacement just doesn't work the way people want it to because you can always replace a transaction by finding a miner willing to ignore the non-final tx in their mempool and willing to mine another one for you. Additionally mempool contents don't last forever; I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.

phelix
Legendary
*
Offline Offline

Activity: 1708
Merit: 1000


nmc:id/phelix


View Profile
February 11, 2013, 10:06:11 AM
 #69

Am I correct in assuming that while this is a serious issue for some sites it does not currently affect most clients and can be fixed for those affected with relative ease?

Once again this makes me wonder if Bitcoin guts really have to be so twisted and complicated. All this just sounds like an invitation to overlook serious issues.

blockchained.com ■ bitcointalk top posts
caveden
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000



View Profile
February 11, 2013, 11:09:38 AM
 #70

I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.

But... doesn't that mean that people were treating a time-locked transaction as normal unconfirmed transaction? They should not be treated as the same thing, that's the actual problem.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1000


View Profile
February 11, 2013, 11:33:54 AM
 #71

I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.

But... doesn't that mean that people were treating a time-locked transaction as normal unconfirmed transaction? They should not be treated as the same thing, that's the actual problem.

That's exactly what people were doing, or really, what the software people were using was doing. Keep in mind that a non-time-locked transaction that depends on a time-locked transaction is effectively time-locked... fixing the issue that way isn't trivial and would have required a lot more careful testing to be absolutely sure it worked; I should know, I wrote a patch that did exactly that kind of analysis before writing a version of the nearly trivial fix that Gavin wrote. It took me a few days to be convinced, but I think he made the right choice. There are also other mostly theoretical vulnerabilities related to non-final transactions that have not been disclosed as far as I know. They are fixed by Gavin's patch and are not fixed by just handling non-final txs differently in the UI. They also can-not be used to steal funds.

Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1005


View Profile
February 11, 2013, 01:29:04 PM
 #72

We can bring time locked and replaceable transactions back when somebody does the work necessary to properly unit test the code, think through the potential issues/angles of attack and patches them, makes sure the DoS/abuse potential is minimized etc.

For now, Luke-Jr has it right - the feature was unused as it's meant to be deployed along side replacement. So we'll have to bring them back together.
pointbiz
Sr. Member
****
Offline Offline

Activity: 433
Merit: 252

1ninja


View Profile
February 11, 2013, 03:23:20 PM
 #73

retep, thank you for the clarifications. Could you TL;DR in the OP? And mention it is patched in 0.8?

Coder of: https://www.bitaddress.org      Thread
Open Source JavaScript Client-Side Bitcoin Wallet Generator
Donations: 1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN   PGP
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!