5

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?
  • 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 Nov 13 '15 at 14:22
2

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.

  • 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 Nov 13 '15 at 14:28
  • 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 Nov 13 '15 at 14:42
  • 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 Nov 13 '15 at 14:55
  • if a miner finds a double spend attempt, will he propagate the transaction further or not? Is there anything special he is doing? – Stefan Nov 13 '15 at 16:32
  • That's up to the miner. – Anonymous Nov 13 '15 at 22:21
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.