Bitcoin in the supermarket – Waiting for confirmations?

One of the often heard criticisms of Bitcoin concerns the relatively long waiting period before a transaction is confirmed: 10 minutes on average. This raises the question how Bitcoin will ever be useful in brick-and-mortar stores where you don’t want to wait for 10 minutes (on average, the time between blocks can be over half an hour!) with your groceries or before you get your coffee. As it turns out, while the security of a confirmed transaction is unmatched, even an unconfirmed transaction is already very useful. And there are techniques that can be used to enhance the security of these so-called 0-confirmation (0-conf) transactions.


The problem: Double-spending

One of the main problems with a decentralized currently that the blockchain concept of Bitcoin solves rather elegantly is the problem of double-spending. Person A sends coins to person B, but (almost) simultaneously sends the same coins to person C (or to himself). With Bitcoin, only one of these two transactions is included in a block and inclusion in a block is almost a guarantee that this transaction will no longer be reverted. And the more blocks that follow that one block that includes your transaction, the stronger the guarantee is.

In the situation where a person pays for a drink or his groceries with Bitcoin, a double-spend attack would involve the person broadcasting a second transaction that tries to spend the same funds he just used to pay for his coffee. This second transaction typically deposits the funds in another address of the attacker. The merchant sees the initial transaction and considers the payment completed, but if the second transaction makes it into a block at the expense of the first, the merchant ends up not receiving any payment.

Why it’s actually not such a problem: Effort versus reward

Bitcoin nodes typically reject a transaction that attempts to spend coins already spent 1. So in order for the merchant to see and acknowledge the payment transaction, it should be broadcast first to ensure that the node of the merchant receives this transaction first. When the second transaction is broadcast afterwards, it should be broadcast to a set of nodes that haven’t seen the first transaction yet. Ideally, this means that the second transaction should be broadcast from a completely different location, across the globe if possible.

At this point it becomes a race to see which transaction has propagated to the miners the fastest. The transaction that first makes it to the miner that ends up finding the next block will probably win. Since the original transaction has a considerable head start, the probability of the double-spend transaction winning the race is very small. Unless the attacker works together with a large mining pool, that promises to include the double-spend transaction at the expense of the original transaction.

Either way, the effort required to make such an attack work is relatively large and even then the outcome is far from guaranteed. The reward, a chance at free coffee or groceries, is definitely not worth the effort. And for more valuable transactions, such as the purchase of electronics or a car, there is typically a delay between the purchase and the delivery of the product and this delay can be used to wait for the transaction to be confirmed.

Additional measures: The payment provider

Since almost all merchants and businesses that accept Bitcoin still pay their suppliers and personnel with the local fiat currency (Euro, Dollar, etc…), they will want to exchange their Bitcoins for fiat currency as they receive it. Because of this, a Bitcoin payment provider, such as BitPay, is typically used, which handles the Bitcoin transaction and pays out the merchant in fiat currency.

An added bonus of using such a payment provider is that they take up the risk of accepting a 0-conf transaction. In the very rare event that a double-spend does occur, the payment provider covers the loss. Of course, this risk is priced into the fee charged by the payment provider, but it does provide the merchant with a clear, risk-free picture of what to expect from each sale.

And more: Transaction propagation, miner deals, etc…

Beyond the protection offered by payment providers there are additional means through which a merchant can greatly reduce (thought not entirely eliminate) the already small risk of a double-spend. One such approach is to measure how much a transaction has propagated through the network. If a large number of nodes run a specific wallet client that reports to a server the transactions it has seen, then this information can be used to make an estimate of the fraction of the network that has seen a transaction. A merchant could then hook up to this server and look up the propagation-status of a payment. Under normal circumstances, the transaction should very quickly spread and in 15-30 seconds the merchant should have a very good idea whether the transaction has reached most nodes or whether it failed to propagate, either due to connectivity issues or due to a double-spend attack.

One could also imagine a large mining pool offering merchants a deal where in exchange for a small payment, the pool would guarantee to include any valid transactions that merchant submits in blocks found by the pool. In practice this would mean that after a customer makes a payment, the merchant submits the payment transaction to the pool and receives an OK from the pool. If this is done with several large pools, a merchant could get the security that the majority of the network is backing this transaction over any potential double-spend attempts. This further reduces the already very small chance of a double-spend succeeding and will also serve to discourage such attempts.

Conclusion: 0-conf? (Almost) 0 problems.

Being able to accept 0-conf transactions with relative safety is a necessity for the adoption of Bitcoin (or any Bitcoin-based crypto-currency) in brick-and-mortar stores and other points-of-sale. Fortunately, 0-conf transactions are already very hard to double-spend, to the point where it becomes uneconomical to do so for the type of transactions that would have to be accepted without confirmations. In addition, the use of a payment provider which takes over the double-spend risk, completely insures the merchant against double-spends, for a fee that is still much lower than conventional payment systems such as credit cards.

In the future, new developments may be deployed that allow a merchant without such an insurance to further reduce the probability of a double-spend being performed successfully. As with many other aspects of Bitcoin, it is simply more economical for people to play by the rules than to try and break them. And an economical incentive to play by the rules is all most people need.

  1. An exception to this is when a transaction that has insufficient fees included is replaced by a double-spend transaction that does include sufficient fees. Any merchant should therefore check (or have his software do this) that a payment transaction contained the right amount of fees.

Leave a Reply

Your email address will not be published. Required fields are marked *