How it works is you try to double spend me. If successful you keep the double spend and I pay you 10:1.
I like those odds!
I did specify that following proper precautions (i.e., no incoming transactions being one of them) will protect the recipient. Using the bitcoin.org client following the default mode is
not a proper protection against someone trying to perform a race attack.
I'ld consider taking you up on your bet if you are using default configuration -- i.e., the client determines which 8 nodes you get connected to. That will likely mean you are not directly connected to any pool (and are at least one hop from a pool).
Then I will make a transaction with a spend to myself and only broadcast that to the top four pools. A few milliseconds later I will, from another node with a copy of the same wallet, announce the double spend to a well connected node that is not one of those four with the hope that the transaction will get relayed to a node you happen to be connected to. It will then be a race -- will the original transaction from one of the four pools reach you first, or will your client see the double-spend transaction first? I wouldn't be surprised if following these steps that your client will show the double spend and the original transaction is what gets mined at least 33% of the time. [Update: Since those four pools only account for about 66% of hashing strength, I dropped the number for the double-spend success percentage guess to 33%.]
Um you don't think the buyer won't happen to notice the tx go INVALID as soon as his client sees both versions of the double spend?
Does the client do anything different now? I thought the client, having a double-spend transaction, just stays at 0/unconfirmed forever. Yes, you'll probably notice that the transaction isn't confirming tens of minutes later but it isn't like seconds after receiving the transaction you get a red popup with a warning.
Trying a Finney attack here means the most likely outcome is the attacker simply loses a block (and 50 BTC).
What I was trying to point out is that a merchant accepting on 1-confirmation can be just as vulnerable to the finney attack as the 0-confirmation should proper precautions (i.e., not allow incoming transactions, be well connected) not be implemented.
So, maybe we can learn something here. I'ld like to see the results of an experiment that determines, using the default configuration for the client on a typical consumer network connection (w/UPnP), how successful the race attack actually is.
For the attacker this can be done using just two node instances each with a copy of the same wallet. (i.e., probably don't even need to go the extra step of having a script running on each of four nodes, to ensure the transaction gets announced simultaneously to the four large pools.)