Trouble Transacting with Bitcoin

Editor’s Note: The following excerpt is adapted from The Gold Standard: Retrospect and Prospect edited by Peter C. Earle and William J. Luther.

One shortcoming of the bitcoin protocol is its limited transactions capacity. In the early stages of bitcoin’s development, Satoshi Nakamoto imposed a block size cap of 1 megabyte (MB). By design, only one block of transactions can be added to the blockchain in a typical ten-minute period. Hence, given the typical size of a bitcoin transaction, a block size cap of 1 MB effectively limits the number of transactions that can be processed by the bitcoin protocol to between 3.3 and 7 transactions per second. For comparison, Visa averages around 1,736 transactions per second and reports the ability to handle more than 24,000 transactions per second.

Initially, the 1 MB block size cap appeared to be of little consequence. Relatively few transactions rendered it a non-binding constraint. But that began to change as the number of users increased. If more transactions are submitted than the system can handle, the time it takes to confirm a given transaction increases. And, since those running the bitcoin protocol can choose which of the submitted transactions to include in a block, some users will find it in their interest to include transaction fees to jump the queue. As a result, other users are forced to pay transaction fees as well or else wait indefinitely as their transactions are routinely overlooked in favor of those including fees. The block size cap, in other words, makes it more costly to transact with bitcoin.

The Blocksize War

Some in the bitcoin community recognized the problem posed by growing congestion and recommended increasing the block size cap over time or eliminating it entirely. Others resisted. Those opposed to increasing the block size worried that it would make the system less secure by increasing the cost of running a bitcoin node. Larger blocks would increase the cost of storing, uploading, and downloading the blockchain. It would also increase the amount of computational power to process transactions. If these costs are sufficiently high, few users will run the bitcoin protocol. And, if few users run the bitcoin protocol, it is more susceptible to attack. Given bitcoin’s governance structure, the deep divisions over what to do have made it difficult to address the congestion problem. Jonathan Bier surveys the history in his excellent and informative book, The Blocksize War.

Bitcoin has a decentralized governance structure, which requires consensus. Recall that the bitcoin protocol designates the longest blockchain as legitimate. It is only legitimate, however, because the consensus of those running the protocol accept it as the true version of the ledger. Likewise, a change to the bitcoin protocol can only result if a consensus in favor of the change can be reached.

To change the bitcoin protocol, one typically submits a Bitcoin Improvement Proposal (BIP) to developers. If a developer thinks the change is warranted, he will implement the change for the network to consider. Then, each user running the protocol can choose to adopt the proposed change by using the revised protocol to process transactions. If those with a majority of the computing power running the protocol accept the change, blocks of transactions will be added to the blockchain using the proposed protocol and recognized as legitimate by consensus. If such a majority is not reached, those running the proposed protocol must choose to either abandon the proposed change, which the majority fails to recognize as legitimate, or fork the blockchain. In the latter case, those proposing the change essentially create a new cryptocurrency that has the same history as the bitcoin blockchain up until the point of the fork. Since the default option is to continue running the traditional protocol, the process is somewhat biased against change.

The most successful effort to deal with on-chain congestion to date resulted from BIP141, more commonly known as Segregated Witness (SegWit), which was activated on August 24, 2017. With the implementation of SegWit, the maximum block size of 1 MB was replaced with a maximum block size of 1 million units. Prior to SegWit, each byte in a transaction was counted as 1 unit. With SegWit, a byte in a transaction continues to count as 1 unit, unless it is part of the witness data. If it is part of the witness data, which has been segregated from the record of the sender and receiver, it is only counted as 0.25 units. The effect of discounting the segregated witness data is similar to increasing the block size cap from 1 to 1.8 MB.

SegWit adoption was slow at first. By January 2018, only around 10 percent of daily transactions employed SegWit. The share climbed following the introduction of the Bitcoin Core SegWit wallet in February 2018. It reached 30 percent in March 2018 and 40 percent in September 2018. By September 2019, the share of daily transactions employing SegWit exceeded 50 percent.

The implementation of SegWit appears to have been a temporary solution, at best. Consider the average transaction fee presented in Figure 1. Transaction fees were less than $0.01 prior to May 2011. From January 2012 to January 2016, they averaged just $0.07. Transaction fees climbed throughout 2016 and 2017, reaching a high of $54.64 in December 2017. They generally declined throughout 2018. From January 2019 to January 2020, transaction fees averaged $1.25; but they were as high as $6.53 in June 2019. Transaction fees began to climb again in early 2020. In March 2021, they exceeded $24.

While SegWit forestalled the rise in transaction fees, it has done little to address the bigger problem with bitcoin’s limited transactions capacity. Bitcoin cannot possibly serve as the sole global payments system in its current form. Suppose SegWit were universally adopted and amounted to an effective increase in the block size of 1.8 MB, as suggested above. That would correspond to a maximum capacity of around 12.6 transactions per second, or a little less than 1.1 million transactions per day. At that capacity, the bitcoin protocol could handle less than 6 percent of payments for the roughly 18.7 million Uber rides each day. In other words, it would fall far short of serving as the sole global payments processor that some of its proponents envision.

Second Layer Solutions

Given the difficulties of changing the bitcoin protocol to increase the number of transactions that can be handled on the blockchain, many in the bitcoin community have turned to second layer solutions. In general, a second layer solution enables multiple transactions to take place between users in a private channel with a single settlement transaction, where the net amount of the private-channel transactions is transferred, and posted on the blockchain. Two examples serve to illustrate.

Suppose a rental car company charges users per mile driven. The company could set up a smart contract that transfers a small amount of bitcoin each time a mile ticks away on the odometer. However, that would require a lot of on-chain transactions. Alternatively, the company could set up the smart contract via a private channel, with the renter automatically sending a small amount of bitcoin to the company each mile on the private channel and the total amount settled on the blockchain once the car is returned. In both scenarios, the rental car company ends up with the same amount of funds. In the second scenario, however, the parties economize on the number of on-chain transfers that are made and, hence, the transaction fees that go along with them.

Consider, next, the relationship between a casino and a gambler. The two parties could settle up after each pull of the slot machine arm. Sometimes the casino would transfer funds to the gambler. But, more often, the gambler would transfer funds to the casino. Of course, that would require a lot of transactions. Alternatively, the two parties could set up a private channel to transfer funds back and forth with each pull and then settle up with a single transaction the blockchain for the net amount when the gambler reaches her limit. As in the previous example, the parties can economize on the number of transactions, reducing the transaction fees incurred and the overall congestion on the bitcoin network.

The most popular second layer solution to date is the Lightning Network, which was proposed in a working paper by Joseph Poon and Dryja Thaddeus in February 2015. To transact on the Lightning Network, one must open a payment channel by committing an on-chain bitcoin funding transaction. The user can then make transactions on the lightning network, which are not broadcast back to the blockchain until the payment channel is closed. In contrast to the simple examples given above, it is unnecessary to set up a direct channel to transact via the Lightning Network. One can send payment to anyone she is connected to and the system will automatically route the payment across the shortest path. The result is a web of second layer transactions. If, at any time, a party drops the channel, the payment channel is closed, with the corresponding off-chain transactions netted out and automatically settled on the blockchain.

By design, the Lightning Network looks a lot like a correspondent banking network. This suggests other banking and banking-system structures might provide second layer functionality with ultimate settlement on the blockchain. Banks issuing claims to bitcoin that only settle occasionally on the blockchain would certainly help reduce congestion. However, they might also mitigate some of the problems with bitcoin’s supply mechanism. To the extent that claims to bitcoin are treated as close substitutes to bitcoin and those claims can expand and contract to meet demand, a bitcoin banking system would provide for a more elastic supply of bitcoin-based monies.

There is no denying that bitcoin is an incredible innovation. It enables individuals to make digital payments without recourse to a trusted third party. However, network effects and government opposition favor the status quo. Moreover, some problems with bitcoin’s design––including its suboptimal supply constraint and limited transactions capacity––cast doubt on the claim that bitcoin is superior to the monies widely used at present. Although there are proposed solutions to these problems, achieving consensus on protocol upgrades is difficult and some users might prefer native solutions to second layer or ancillary institutional fixes. Taken together, these issues suggest bitcoin might fail to gain widespread acceptance despite its remarkable innovation.

Related Articles – Cryptocurrency, Economic Education, Financial Markets