BitPay Wants to Do Away With Confirmation Time

For those of you who have tried to buy things in person with Bitcoin, you know the frustration of transaction delays. Due to the underlying structure of the network, transactions can’t be counted as having any kind of finality until they’re added to a new block, which are produced only every ten minutes. Even then, they can’t be treated as functionally irreversible in the case of a double-spend attack until they’re several blocks deep in the chain, which takes proportionally longer.

This doesn’t matter so much when you’re buying from an online retailer: the average-ten-minute delay gets swallowed up in the time it takes to download or ship the content in most cases. However, in person, the delay is a lot more pernicious – waiting around for ten or twenty minutes for your transaction to go through is a serious barrier to commerce. In practice, for small purchases of a few dollars, a zero-confirmation transaction that’s already been propagated to the network is probably decently secure. This is because all of the attacks that could be used in such a scenario are more expensive than the cost of the transaction itself, which makes it unlikely that your customer is planning an attack on the network.

Still, it’d be nice to have some middle ground between the extreme but slow security of a multi-confirmation transaction and the fast but insecure zero-confirmation transaction. That is, roughly speaking, what BitPay recently proposed, in the form of “Impulse.”

It works like this: Before you go to the grocery store, you pre-load your spending money into a multi-sig wallet, which is designed such that it needs signatures from both of its keys in order to make a transaction – it’s also designed with a time lock, such that, if no transactions are made after a certain amount of time, its money is refunded safely to the user. The user would have control of one key, and the other would go to a payment processor, which would detect co-sign when the user wants to make a transaction, and then refuse to sign any other transactions until the first one is well-confirmed.

The merchant, seeing the transaction address of the payment processor on the transaction, can have a degree of trust in the payment processor that the transaction will go through, despite being unconfirmed. The user, thanks to the lock-time feature, doesn’t have to have any trust in the processor: there’s no way for the processor to steal their funds (which also removes most perverse incentives for the payment processor. The primary form of risk in the system is the possibility that the payment processor is colluding with the customer to defraud the merchant, something that makes very little sense for an established payment processor except for extremely large transactions. In those cases, an extra hour or two to wait for real confirmation is probably acceptable.

Essentially, BitPay wants to create organizations that can serve to mitigate some counterparty risk, introducing a small measure of trust to allow zero-confirmation transactions to be accepted by retailers safely. This is ultimately a stopgap measure, and it’d be nice to implement a fully decentralized solution, but it’s difficult to imagine what such a solution would look like. There are a few schemes under consideration which are similar to the BitPay proposal, including the so-called “No Risk Wallet,” which is the product of the Amsterdam Bitcoin Hackathon, and Instawallet’s GreenAddress feature. It remains to be seen which of these solutions, if any, will ultimately be widely adopted.