One of the crucial features for a digital transaction medium to be viable for payments made in person is that it should be reliable, and nearly instant. A transaction, once created by the sender, should appear on the receiver’s device within one to three seconds. Even five seconds may be acceptable, but from the point of view of an average user requiring a customer and merchant to awkwardly wait for fifteen seconds while a transaction makes its way over the network is an embarrassment – especially when competing platforms like Square can accomplish the same (albeit without Bitcoin’s low fees and universality) in less than three. And yet, in practice, that is all too often the state of in-person Bitcoin transactions right now. A transaction sent with Blockchain may take as long as twenty seconds to reach a nearby client running Bitcoin Wallet for Android and if the transaction is non-standard in certain ways (eg. by not having a fee) it can take several minutes or even hours to show.
To understand why this happens, it is first important to understand the most common case in which it does not happen: when the sender and receiver are both blockchain.info. Blockchain.info differs from other popular wallets, like Bitcoin Wallet for Android, in that it is semi-centralized; although blockchain.info is still using the same, decentralized, underlying Bitcoin protocol as everyone else, the wallets themselves send and receive transactions from the rest of the world through blockchain.info’s centralized servers. The transactions are all immediately rebroadcast to the Bitcoin network, so this makes no difference in the long term, but in the short term this provides a significant advantage. If the sender and receiver are both using blockchain.info wallets, the transaction only needs to make two hops: sender, blockchain.info, receiver. The blockchain.info server stores all transactions that are legal under the protocol, so even transactions with dust outputs, or without fees, are relayed to the receiver without problems.
If one of the two is using something else for a wallet, however, then the situation gets more complicated. The transaction needs to make many hops through the Bitcoin network, and be validated each time, in order to reach the receiver. There is also another complication. The bitcoind client, responsible for the vast majority of the Bitcoin network, enforces some rules on what transactions it is willing to relay (for example, transactions spending newly received coins must have at least a very small fee), and if a transaction violates any of these rules propagation time through the Bitcoin network slows to a crawl. Even if a transaction does not violate any of these rules, it often takes as much as ten seconds to get through.
So what are the consequences of this? Essentially, centralized wallet services may, to a small extent, become their own walled gardens – that is to say, balkanization. Sending bitcoins from blockchain.info to blockchain.info is instant, as is Bitcoin Spinner to Bitcoin Spinner, but sending from blockchain.info to Coinbase is more difficult. The problem with walled gardens, however, is the old adage called Metcalfe’s Law: “the value of a telecommunications network is proportional to the square of the number of users”. If blockchain.info has 50% of the mobile wallet market and Bitcoin Spinner has 10%, then blockchain.info is not just better than Bitcoin Spinner because of whatever features drive five times as many users to its service in the first place; it is also better because it offers instant transactions to a larger number of users. It is clear how this naturally leads to monopoly.
One solution to the problem involves an optional layer of centralization. Blockchain.info offers a page, blockchain.info/pushtx, where anyone can submit a transaction into blockchain.info’s servers; the first step is that all other centralized wallet providers, and Bitcoin network information sites, should do the same. Second, centralized services should agree to either push all transactions to each other deliberately, perhaps through specialized channels, or even co-locate servers in the same data center. Finally, decentralized wallets should automatically push all transactions to these transaction submission hotspots at the same time as releasing them to the network. This does not compromise Bitcoin in any way; all of the old infrastructure remains in place, so a non-participating wallet will still be at least as fast, if not faster, than before. Rather, it adds an optional “clearing” layer to help transactions move through faster.
Another solution is to add more information into payment requests. Currently, merchant platforms and Bitcoin wallets can typically only generate QR codes with two pieces of data: the Bitcoin address to pay to and the amount to pay. Consider what would happen if the protocol were to add a third piece of data: the receiving wallet’s IP address. Then, when the sender scans the QR code and pays, the wallet could send the transaction to the sender directly. If the receiver has no publicly reachable IP address (eg. the address is masked by NAT), a Bitcoin client that does have a publicly reachable IP address can be used to act as a go-between. In this case, the transaction would take one or two hops to reach the receiver – as fast as with blockchain.info to blockchain.info transactions in the worst case, and even faster in the best case.
Whichever solution we will take, some kind of optimizations to make Bitcoin faster are necessary. Companies like Square are spending millions of dollars shaving hundreds of milliseconds off their transaction time to make the user experience more pleasant. Tech enthusiasts may be happy to withstand the struggles of slow and unreliable transactions for the sake of a cool new technology, but one average users enter the picture it is small optimizations like those that make all the difference. Bitcoin itself is just on the cusp of moving from the tech enthusiast crowd to the first signs of general usage, and so now is the time for us to start taking these finer points of ease of use seriously. The other solution, for the Bitcoin community to simply say “this is one of the faults of a decentralized system, deal with it”, is no longer acceptable.
