Bitcoin Forum
December 10, 2016, 03:29:07 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: 2012-05-03 Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Pa  (Read 1320 times)
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
May 03, 2012, 11:01:53 PM
 #1

Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin
 - http://eprint.iacr.org/2012/248.pdf

Research paper on double spending.  

Discussion thread here:
 - http://bitcointalk.org/index.php?topic=79090.0

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

Posts: 1481340547

View Profile Personal Message (Offline)

Ignore
1481340547
Reply with quote  #2

1481340547
Report to moderator
1481340547
Hero Member
*
Offline Offline

Posts: 1481340547

View Profile Personal Message (Offline)

Ignore
1481340547
Reply with quote  #2

1481340547
Report to moderator
1481340547
Hero Member
*
Offline Offline

Posts: 1481340547

View Profile Personal Message (Offline)

Ignore
1481340547
Reply with quote  #2

1481340547
Report to moderator
PawShaker
Full Member
***
Offline Offline

Activity: 140



View Profile
May 04, 2012, 06:31:50 AM
 #2

Very good paper and very timely.

Propagating alert is a very good idea, and I wonder why it was not implemented in the first place. Does it allow to flood the network with false alerts? I do not think so, because both TR_A and TR_V must be included in the alert.

However, I can see an opportunity to flood the network with alerts by very heavily overspending. Attempt to spend the same coin N times will generate O(N^2) alerts. An attempt to quadruple (4) spend the same bitcoin will generate 6 alerts to propagate through the network. An attempt to spend 5 times will generate 10 alerts. An attempt to spend 6 times will generate 15 alerts and so on. If someone wants to overload BitCoin network, he will overspend the same coin 100 times and send each transaction to a different peer. This will generate 4950 alerts! Nice DDoS opportunity!

The algorithm to generate alerts must be a little bit smarter. The alert must not be propagated if node has already sent (or propagated) an alert for similar (or identical) collision.

1FQkH63k6hkexFMTRzLtJEE6ZAaTBRhjiS
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
May 04, 2012, 07:02:56 AM
 #3

Very good paper and very timely.

Propagating alert is a very good idea, and I wonder why it was not implemented in the first place. Does it allow to flood the network with false alerts? I do not think so, because both TR_A and TR_V must be included in the alert.

However, I can see an opportunity to flood the network with alerts by very heavily overspending. Attempt to spend the same coin N times will generate O(N^2) alerts. An attempt to quadruple (4) spend the same bitcoin will generate 6 alerts to propagate through the network. An attempt to spend 5 times will generate 10 alerts. An attempt to spend 6 times will generate 15 alerts and so on. If someone wants to overload BitCoin network, he will overspend the same coin 100 times and send each transaction to a different peer. This will generate 4950 alerts! Nice DDoS opportunity!

The algorithm to generate alerts must be a little bit smarter. The alert must not be propagated if node has already sent (or propagated) an alert for similar (or identical) collision.


Right now it notices the repeated use of the same inputs and ignores it right? It could ignore unless it was related to a payment to your wallet no? In that case it should change the tx from 'unconfirmed' to 'warning' or similar and ignore it. By ignore I mean don't pass on as you normally would.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
PawShaker
Full Member
***
Offline Offline

Activity: 140



View Profile
May 04, 2012, 08:43:02 AM
 #4

[...]
Right now it notices the repeated use of the same inputs and ignores it right? It could ignore unless it was related to a payment to your wallet no? In that case it should change the tx from 'unconfirmed' to 'warning' or similar and ignore it. By ignore I mean don't pass on as you normally would.

Not quite. The detection may happen somwhere in the world. It will be a random nodes which happen to be at the border of two "floods" of propagating messages. Think about it like a pond of water and you drop two pices of paint: blue and yellow. Water around paint starts to get coloured till two areas touch. You will see green colour there, this is detection point. This point may be quite far from the node which is interested in this information. This is why it is important to propagate this information to everyone.

Currently, area already painted blue ignors yellow pigment and area already painted yellow ignores blue paint. Currently paints do not mix, they wait till a block is generated. If block is generated in ble region then one version is assumed as legal. If in yellow, the other one. Only when valid block is generated, a judgment is passed and propagated to everyone.

1FQkH63k6hkexFMTRzLtJEE6ZAaTBRhjiS
zby
Legendary
*
Offline Offline

Activity: 1431


View Profile
May 04, 2012, 11:06:33 AM
 #5

Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin
 - http://eprint.iacr.org/2012/248.pdf

Research paper on double spending.  

Discussion thread here:
 - http://bitcointalk.org/index.php?topic=79090.0
Please add that this is relevant only for 0-conf transactions which were never considered to be secure, otherwise it is very alarmist.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
May 04, 2012, 11:17:03 AM
 #6


Please add that this is relevant only for 0-conf transactions which were never considered to be secure, otherwise it is very alarmist.

And that they didn't follow the basic recommendation:
 - No incoming traffic (e.g., no port forwarding to the client, and no UPnP)
 - Explicit connections to well-known nodes (e.g., large pool miners).

Their results would not have been the same.

lonelyminer (Peter Šurda)
Donator
Hero Member
*
Offline Offline

Activity: 544


View Profile
May 04, 2012, 01:50:35 PM
 #7

I think the crucial point of the paper, as the authors argue, is that performing 0-confirmation attack is easier to do than previously thought. That's a valid argument. We need to understand how Bitcoin works so that we can do risk assessment and mitigation. I'm sure that as time progresses, solutions other than what the authors recommend and others than zipconf will pop up.
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
May 05, 2012, 02:05:36 AM
 #8

The victim experiences this as a tx that just won't confirm correct? The tx doesn't entirely disappear?

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
lonelyminer (Peter Šurda)
Donator
Hero Member
*
Offline Offline

Activity: 544


View Profile
May 05, 2012, 05:55:18 AM
 #9

If I got it right, the current implementation would cause the transaction to show "0 / unconfirmed" until a block is mined. If the attack was successful, the transaction presumably vanishes after that.
Pages: [1]
  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!