Topic: Best practice for fast transaction acceptance - how high is the risk? - page 4. (Read 26589 times)

Presumably, a commercial bitcoin payment processor would spend the bucks to enter the network at a wide array of points, implementing their own double-spending detection and prevention.

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

Suppose the attacker is generating blocks occasionally. in each block he generates, he includes a transfer from address A to address B, both of which he controls.

To cheat you, when he generates a block, he doesn't broadcast it. Instead, he runs down to your store and makes a payment to your address C with his address A. You wait a few seconds, don't hear anything, and transfer the goods. He broadcasts his block now, and his transaction will take precedence over yours.

You need >50% of the computational power to get 6 confirmations. For 1 confirmation, 1% of CPU power will give you about a 1% chance of being able to reverse the transaction, regardless of how well the original transaction propagated.

If the attacker can't do that, then broadcasting and waiting a few seconds does give a good chance that there will be no double-spending. However, nodes will not relay transactions they consider bad, so you might not see bad transactions until they're in a block. This is why a centralized "super node" with many connections is desired. And Bitcoin doesn't currently warn you about double-spends, anyway.

Scenario: You, as a merchant, would like to allow for quick payment with Bitcoins - for example at a supermarket - and therefore 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.

I know that this scenario has been discussed already to some extend in the snack machine thread (https://bitcointalksearch.org/topic/m.3647) but it went a little off-topic there I thought, with people suggesting central or semi-central solutions to accomplish this. Central solutions are what we have today, they are not the answer. Whatever is needed to do fast transaction confirmation will need to be decentral.

In any case, I would like to hear your thoughts and attack scenarios on the procedure outlined above. How high is the risk of accepting transactions in this way? My assumption is, that the attacker does not have more than 50% of the CPU power of the network available to him, but might be able to control a large number of IP addresses.

Once the transaction is broadcasted to all nodes, they will start working on including it in the next block. The attacker can not outpace that (see assumption) so his only chance is to get his double-spend transaction to spread through the network faster and thus have more nodes working on including his second transaction. In that case though, I - as the merchant - will also receive the second transaction in a matter of seconds and notice the double-spend attempt. So I can only think of one attack scenario: The attacker controls a large number of IP addresses and - after waiting for a while - hopes that I am only connected to nodes controlled by the attacker. The attacker is now free to selectively forward transactions from the rest of the network to me and thus be able to prevent me from seeing the double-spend transaction too early.

Is this really the only attack scenario? Am I missing other risks that I would expose myself too?