2012-05-03 Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Pa

[Stephen Gornick]

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

[PawShaker]

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.

[FreeMoney]

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.

[PawShaker]

[...]
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.

[zby]

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]

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)]

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]

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

[lonelyminer (Peter Šurda)]

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.