Scenario: You can't wait around for one or several confirmation blocks. Instead, you receive the transaction, broadcast it to nodes you know and wait for a couple of seconds to see if you notice any double-spend attempts. If not, you accept the payment right away.
In the current Bitcoin scheme, one can't accept transactions until it has been incorporated into a block. Suppose two transactions "spending the same coins" enter the network at different points. On average, half the network will have one transaction and half the other. The only way out of this deadlock is which happens to make it into a block first. So you can see that the race across the network is unimportant but the race to get into a block is the deciding factor.
Hal's attack above would yield a reliable income.
ByteCoin
We could update bitcoin client with the following modifications:
- if 2 double-spend transactions received within 20 seconds of each other ==> ordering unknown. Accept blocks with either transaction, and build on top of the longest chain. (Current implementation)
- if 2 double-spend transactions received more than 20 seconds apart ==> ordering known. Reject all blocks that include the later, non-original transaction(s). Do not build on top of the rejected block.
- stop rejecting blocks containing double-spend transactions if the block receives 6 confirmations (to prevent a permanent chain fork)
- clients should relay double spend transactions to alert the recipients that there was a double spend attempt.
If we do this, then fast payments will be possible using the method laid out by the original poster.