Topic: The risk of the double spend (or why we don't need to wait for confirmations) (Read 1628 times)

Perhaps, but I would think that if this were to start happening, something could be done about it.  I can think of a couple of different ways that repeatedly doing this kind of attack could bring the attention of the rest of the network to the attacker's IP address.  It's not that an individual node cannot be discovered with the help of the majority of the rest of the network.

That's just it though. If you can rip off an eCommerce provider by 300BTC (10 * 30 BTC transactions) every 30 minutes because your GPU is capable of some 33% of the entire hashing power of the network, that's worth the effort. If you can rip off an eCommerce provider by 300BTC once every 6 months then it's no longer worth it, so I think hashing power is critical in the practicality of this attack.

Bitcoin currently doesn't detect this. The transaction that loses will sit at "0/unconfirmed" forever.

I was amazed when I saw that Bitcoin2CC gives out credit cards with 0 confirmations. This is incredibly dangerous.

You can't really assume that all nodes will ever see both transactions.  Since nodes won't propagate invalid transactions, and your two starting nodes send their transactions to all peers by default, none of their peers will ever transmit those other transactions to the two vendor's clients.  That is, unless those two clients happen to be connected to one another directly, in which case the double spend would fail from the start.  One way to mitigate this, is for ecommerce clients to randomly choose one peer to not send the transaction to, and listen to that peer for the transaction that they sent to echo back.  If their transaction comes back, it's incrediblely unlikely that said ecommerce site will get shafted, even if a double spend attack was attempted, because if they see it, then they probably have the wider dispersed transaction anyway.  If they see any other transaction come across that peer trying to spend those same coins, the sale is simply denied.


I believe that it would show up as 0/unconfirmed in the client, and that those coins would never be added to the total balance displayed by the client.

Only if your ecommecre client is configured to assume a valid transaction is good, which is certainly not the default way of doing things thus far, but not unreasonable for smaller value sales.  Say, anything under $50.

Double spending is identical to writing hot checks. If it happens, it will likely be an isolated incident.

Doesn't really matter.  What you would have to do to attempt a Finney attack is have a script that can spend your coins the instant that you find a block, withhold that block for half a second, and then hope that no one else solved that same block within that half second.  Faster hashing just means that you don't have to wait as long to try it.

Like the double spend attack, the Finney attack can be defended against without confirmations; simply by delaying the completion of the sale for a couple seconds and watching for a block and/or transaction that competes with it propagate across the network.  Both attacks would be futile for any site that sold products that physically shipped, since the sale can be cancelled if the transaction is found to be false.

How much of a GPU would you need for this to be practical? My PC is 3 years old, and my GPU mining efforts showed approximately 120 days between finding blocks! Even at 7 days per block (I guess some high end consumer GPUs could do that?), how much would need to be spent in a double spend attack to make it worthwhile?

Presumably it wouldn't be worth it for a 10c transaction, and impossible with a 10,000BTC transaction (as the seller would wait for confirmations), so I wonder what is considered a "safe" value below which you might as well take zero confirmations as "good enough" considering the difficulty of launching a Finney attack.

Or would we expect to see botnets finding blocks, meaning the time between launching double spends could be as little as one every 20-30 minutes (approximate time between blocks for something like mining.bitcoin.cz), and that's what the main problem is?

No, today it is better to do the Finney attack if you have mining resources like a gpu. Just mine as normal but include a transaction spending some of your own coins back to yourself. When you eventually find a block, spend those coins at the ecommerce store, then broadcast your solved block.

It relies on the attacker being able to buy something from you quickly and at a time of their choosing.

This is a follow on from other threads: https://bitcointalksearch.org/topic/what-is-a-confirmation-1994 and https://bitcointalksearch.org/topic/best-practice-for-fast-transaction-acceptance-how-high-is-the-risk-3441 and https://bitcointalksearch.org/topic/bitcoin-snack-machine-fast-transaction-problem-423

Specifically, I want to limit this discussion to the CURRENT implementation: no suggestions on how to make BitCoin better, no suggestions working around what might not even be a "problem". I just want to know:

In the current implementation, what are the circumstances that would need to be created that might leave someone out of pocket, if they accepted transactions without waiting for confirmation? Here's my understanding based on reading the other threads and the wiki, but if someone could confirm that would be great.

Attacker has some bitcoins, and is connected directly to the nodes of the eCommerce sites he's attacking, one in Chile and one in Mongolia. At almost exactly the same time, his modified client directly sends Transaction A to Chile node and Transaction B to Mongolia node, so each of those respective clients see the transaction as unconfirmed.

The two nodes start propagating, and we're now 100ms in. Because of normal lag and so on, transaction A propagates to 40% of the network, transaction B to 20% of the network, and no nodes have yet detected a double spend. At 110ms in, a node in Africa (which has already received transaction A) also receives transaction B, and considers it invalid, thus not propagating it. By 300ms in, every node has received both transactions but 70% of the nodes accepted transaction A (considering transaction B to be invalid) and 30% of the nodes accepted transaction B (considering transaction A to be invalid).

But both the Chile and the Mongolia nodes both say they have received the money.

After 15 minutes, a new block is generated within the 30% of the nodes thus including transaction B and excluding transaction A. The new block propagates around all the nodes, causing the Chile node to drop the received money transaction (this shows up in the client as something or does it just vanish?), while the Mongolia node carries on as if nothing had happened.

Is this how it works in the current implementation? For 15 minutes, or however long it takes for the next block to arrive, both eCommerce sites will think they've received the money?