Bitcoin Forum
December 03, 2021, 09:36:41 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1  (Read 3776 times)
jedunnigan
Sr. Member
****
Offline Offline

Activity: 279
Merit: 250


View Profile
July 06, 2013, 04:13:36 PM
 #1

Not sure if this is a widely known issue but I stumbled across it this morning thought I would share it with you guys...

Quote
Abstract: In this article, we discuss a possible exploit in Bitcoin that arises from the simultaneous adoption of client versions 0.8.1 and 0.8.2 (or 0.8.3) in the network. In version 0.8.2, Bitcoin clients no longer accept transactions with non-strict signature encoding. As we show, this incompatibility with prior client versions can potentially lead to a double-spending attack in a fast payment setting in Bitcoin. The attack can only work when merchants operate on any client version prior to 0.8.2. Our aim is therefore to raise the awareness of merchants to adopt version 0.8.2 (or 0.8.3) if they are willing to accept fast payments.

Source: http://e-collection.library.ethz.ch/view/eth:7083
1638567401
Hero Member
*
Offline Offline

Posts: 1638567401

View Profile Personal Message (Offline)

Ignore
1638567401
Reply with quote  #2

1638567401
Report to moderator
1638567401
Hero Member
*
Offline Offline

Posts: 1638567401

View Profile Personal Message (Offline)

Ignore
1638567401
Reply with quote  #2

1638567401
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jdillon
Member
**
Offline Offline

Activity: 70
Merit: 17


View Profile
July 06, 2013, 06:34:37 PM
Merited by ETFbitcoin (3)
 #2

The Bitcoin developers are well aware of this non-issue: http://sourceforge.net/mailarchive/forum.php?thread_name=CAJHLa0MVrQN6hyuAsYNRJ2CV6fsPnAbRDSUQH%2Bn6jfKdMiFaLQ%40mail.gmail.com&forum_name=bitcoin-development Every change to Bitcoin that blocks some transactions from propagating for any reason, such as them being harmful to the network, has this effect.

Zero-conf transactions have never been safe. For instance as pointed out on irc by Peter Todd because Elgius has 3.17% of the hashing power and blocks Satoshidice transactions you can profitably double-spend Satoshidice in principle, earning the different between the 3.17% hashing power and the Satoshidice 1.9% house edge each time. (actually doing so profitably is difficult however due to the risk of ruin among other things) You can get an even better edge by identifying all the miners blocking Satoshidice transactions and submitting to all them simultaneously, and you can further improve upon that edge by identifying miners blocking other addresses as well such as the "correct horse battery staple" address that was used to spam the network.

Never mind that because Bitcoin does not implement double-spend detection the vast majority of clients would never know if you simply broadcast two conflicting transactions at once. In that case there is a 50:50 chance of the transaction to the merchant being mined. Blockchain.info even created a easy to use tool to automate doing this: https://blockchain.info/create-double-spend (although it's hard to click both "send" buttons fast enough for it to work, it works better if you submit one transaction on your local bitcoin node)

However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.

Peter Todd is working on writing better memory pool code that will enable this technology for safe zero-confirmation transactions, although he has told me it won't be ready for awhile due to the careful testing required, and it only makes zero-confirmation transactions safer in proportional to the miners who adopt replace-by-fee. (currently about 0.25% by my ad-hoc measurements) That said if a reasonably large fraction support it, simply asking for a risk deposit as mentioned above or some other insurance method is an adequate approach to deal with the % of miners who will ignore the counter-transaction.

It remains an open question as to whether or not the core developers accept the changes required for safe zero-confirmation transactions, Gregory Maxwell's comments on the idea are worth reading: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02226.html
jedunnigan
Sr. Member
****
Offline Offline

Activity: 279
Merit: 250


View Profile
July 06, 2013, 11:39:57 PM
 #3

However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.

Peter Todd is working on writing better memory pool code that will enable this technology for safe zero-confirmation transactions, although he has told me it won't be ready for awhile due to the careful testing required, and it only makes zero-confirmation transactions safer in proportional to the miners who adopt replace-by-fee. (currently about 0.25% by my ad-hoc measurements) That said if a reasonably large fraction support it, simply asking for a risk deposit as mentioned above or some other insurance method is an adequate approach to deal with the % of miners who will ignore the counter-transaction.

It remains an open question as to whether or not the core developers accept the changes required for safe zero-confirmation transactions, Gregory Maxwell's comments on the idea are worth reading: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02226.html

Thank you for the thorough reply, quite informative. Much appreciated.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!