Quote from: sverre on March 28, 2011, 07:18:23 AM

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

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.

Quote

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.

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.

Quote

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?

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.