0/confirmation race attack double spend transactions

I am developing a point of sale bitcoin app, which should accept "fast" transactions (~30 sec for merchant to accept). I researched double spending questions here already, but it is still unclear to me, what happens within the time frame before a transaction is actually included into a block.

Considering the case of a double spend attempt, where an attacker needs to pay to a merchant. The attacker creates and propagates a respective transaction A into the the bitcoin network. Transaction A is added to the main memory of mining nodes and is "waiting" for inclusion into one of the next blocks. The merchant is informed of the propagation of transaction A by the nodes he is connected to. Before transaction A is actually included in a block, the attacker creates and propagates another transaction B, which has the same inputs as A (double spend).

What happens if a miner (which has transaction A in his main memory) gets the conflicting transaction B?
Can a merchant be sure, that transaction A will be confirmed, if it is propagated successfully to let's say all or most miners?
Would a miner throw away transaction A and include B, if B has higher transaction fees, a smaller size in bytes, or of other attribute?

Stefan

Posted 2015-11-13T12:30:49.583

Reputation: 345

Basically what you'd need is something like the Lightning Network. But that is by no means operational yet and will likely take more than a year before you can reasonably start testing. And longer before there's enough adoption by wallets and users. – Jannes – 2015-11-13T14:22:30.730

Answers

The bottom line is that there is no way for you to safely accept zero confirmation transactions.

What happens if a miner (which has transaction A in his main memory) gets the conflicting transaction B?

Depends on what software the miner is running and how they have configured it.

Some nodes will reject it.
Some nodes will accept it.
Some nodes will accept it conditionally.

There's no knowing what people are running on mining nodes or what rules they have.

Would a miner throw away transaction A and include B, if B has higher transaction fees, a smaller size in bytes, or of other attribute?

Ditto.

Can a merchant be sure, that transaction A will be confirmed, if it is propagated successfully to let's say all or most miners?

Absolutely not.

An alternative can be mined at any time, invalidating the original. This attack has been used in the real world to defraud websites of their Bitcoin payments to the tune of millions of dollars. Successful double spends can even happen once the transaction has been included in a block, which is why a large number of confirmations is suggested for people accepting Bitcoin as payment for services.

Anonymous

Posted 2015-11-13T12:30:49.583

Reputation: 10 054

Hmm, so if this is all true, reliable transactions cannot be done in a POS setting. Either one is doing something like payment channels, or living with the risk. Nobody would wait for more than 10 minutes at the counter after a purchase. – Stefan – 2015-11-13T14:28:56.933

however there is this company blockcypher, which calculates a confidence value for an unconfirmed transaction. What other approach could be used, if not how far a transaction is propagated into the network to calculate such a value? – Stefan – 2015-11-13T14:42:35.007

It's easy to sell nonsense metrics if people don't understand what they mean. Miners can include whatever they want, irrespective of what people think is in peoples memory pools. – Anonymous – 2015-11-13T14:55:09.433

if a miner finds a double spend attempt, will he propagate the transaction further or not? Is there anything special he is doing? – Stefan – 2015-11-13T16:32:54.900

That's up to the miner. – Anonymous – 2015-11-13T22:21:26.540

Relying on an unconfirmed transaction is much riskier than relying on 1-confirmed transaction. And in turn, relying on a 1-confirmed transaction is risker than relying on a 2-confirmed transaction.

This will always be a choice best made on empirical data. One of the more disappointing ideas is that, because 0-conf is less safe, all use of it should be eradicated.

Tom Harding

Posted 2015-11-13T12:30:49.583

Reputation: 336