Bitcoin Scaling: How do we know when we’ve got it right?

The following text is adapted from a paper I wrote in the first half of 2016. I clipped a good bit out and could have revised a bit more for this post. So if you are already familiar with bitcoin I’d recommend skimming ahead to the “Modeling Social Benefit of Proposed Solutions” section as the main point I’d like to drive home here is that what Bitcoin scaling needs to be done right is a model based off the Marshallian surplus model. There are way too many programmers and not enough economists in this debate.

Just to be clear, I supported the 2mb block increase for quite some time. However, I support segwit now that it is ready for deployment — although I see it as a terribly complex solution for a simple problem. Ideally the blocksize limit would have been raised, then something like segwit could have been created and deployed at a more leisurely pace and it would buy time for the kind of model I describe to be created for future size determinations. However, as the model below touches on, these sort of solutions are being discussed and examined often without real economic examination. Bitcoin desperately needs a dispassionate “rule” for what the best path forward (defined as the best possible shared outcome for users and miners) is with regard to scaling, the model I’m proposing can do just that.

— — — — — — — — — — — — — -

Bitcoin Growth: 
 A Comparison of Scaling and Capacity Options Available

Ryan J. Martin

The bitcoin network is rapidly approaching a point where users wishing to complete a transaction on the network’s distributed ledger, the blockchain and willing to pay a fee comparable to other digital currencies will find themselves priced out of the market. This will have the effect of users turning to third party transaction processors that will require trust and this creates counter-party risk, in addition to centralizing what is meant to be a decentralized payment system. Eventual solutions such as segregated witness and, more effectively, the lightning network are laudable solutions but may not be able to be deployed and implemented in a timely enough fashion to prevent bitcoin from losing its place as the primary digital currency. To maximize net social benefit and to increase transaction throughput in the near-term, the hard limit for the block size should be increased from 1 megabyte to 2 megabyte. .
The medium and long-term will require a flexible limit that automatically adjusts to maximize social benefit according to a Marshallian surplus style-model. The model will work under the assumption that the memory pool will be “full” at all times, as this is inevitable if Bitcoin is successful. This model will maximize benefit to users and miners will minimizing burden. Proposals to unlimit the blocksize maximize user benefit at miners’ expense. Leaving the cap at 1MB — -especially without payment channels — -maximizes miner benefit at the cost of users. Marshallian surplus models have been adapted to optimize taxation, reduce enviromental externalities, and are a powerful tool for finding equitable solutions.

Roadblocks to scaling bitcoin

Up until recently there have been few occasions where more than 2000 fee-paying transactions are “waiting” in the mempool. But as Bitcoin has grown in popularity and usage the demand for transaction processing has steadily increased. The reason only 2,000 transactions can be stored is due to a rule in the protocol which states that the maximum data size a block can be is 1 megabyte. The average transaction is approximately 500 bytes, meaning 1 kilobyte can hold about two transactions and 1 megabyte is equal to 1,000 kilobytes. Relative to other payment systems, this means that bitcoin can only handle around 3.5 transactions per second, while Visa by comparison handles about 2,000 per second and has reached peaks of 47,000 transactions per second.

As a result of this reality, some within the Bitcoin community have proposed formulas to continually raise the maximum block size limit over time. However this solution is not practical in the long term. To get to a capacity of 2,000 transactions per second blocks would have to be around 550 megabytes in size. This is not practical as all miners need to be able to communicate as quickly as possible and to have a copy of the newest block added to their copy of the blockchain. Bandwidth and storage limitations make this unviable as a solution any time in the near future.

There has been some examination of this quandary within the academic and professional communities. However, these analysis often view the problem through the lens of a computer scientist rather than an economist. Certainly both considerations are inextricably linked and no worthwhile examination can focus solely on one. This analysis will attempt to compare the economic considerations of the different paths forward for scaling in terms of what maximizes total social benefit and maximizes the long term viability of Bitcoin.

Proposed Solutions

Recent analysis by Croman, Decker, et al. suggests that under the current limitations of the network the blocksize limit should be set at 4MB. However the capacity of this is what shows how this is not a long-term solution. A block limit at 4MB would only be about 13 transactions per second. Even as bandwidth, storage, and alike increase in capacity the blocksize cannot grow indefinitely and would likely outpace technological growth. The reality is that the more Bitcoin succeeds in terms of usage adoption, the more its decentralized nature becomes put at risk. This seemingly paradoxical notion rests on the fact that transactions will eventually have to be moved off-chain, with third parties processing transactions as demand for sending/receiving Bitcoin exceeds its capacity. Raising the blocksize limit is no panacea however.

If Bitcoin is ever to become truly widespread in terms of usage, the blocksize limit would have to be enormous or transactions would have to be processed “off-chain.” As Nakamoto himself took note of since Bitcoin’s inception:

“… As the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.

The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. 
 That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.”

Nakamoto is outlining a variation of the other dominate solution to Bitcoin’s capacity and scaling problem. This solution proposes completing transactions “off-chain”, which — -without significant protocol changes — -creates a number of problems. By itself having transactions processed by a third party runs counter to what makes Bitcoin so powerful: the notion of a decentralized public ledger. Some have posited that this is actually enhancing decentralization by having more transactions processed and would increase the number of full nodes. However, as an example, say 8000 users wish to send bitcoin on the next block, but only 2000 transactions could be processed on the blockchain, 6000 would be processed in blocks much later or by third-parties willing to accept lesser fees to process them off-chain. There could be many entities to do this or possibly 1 or zero. Zero is problematic since Bitcoin would become a settlement network rather than a liquid currency. One (or even a few) would mean that a singular, central entity would be handling two thirds of all Bitcoin transaction processing and this entity would have to be trusted by users, which creates counter-party risk and opens the possibility to transactions no longer being immutable or publicly verifiable. This solution, in the form just described, is untenable but a likely outcome if there is not any other option for users wishing to transfer bitcoins without a significant fee. This is by far the worst outcome available but still represents a scenario that deserves examination as it is still a possible outcome. If inaction is the chosen path as demand exceeds capacity this will be the outcome.

Surprisingly however, a modified form of this off-chain scaling solution has led to a surprisingly viable option. In their proposal “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”, J. Poon and T. Dryja propose an ambitious solution. While highly complex, it would allow transactions to be completed off-chain but with the benefit of still being trustless, non-reversible, and immutable. The transfers wouldn’t require any third party, but would require two users wishing to transfer money to enter a signed transaction (more akin to a contract) that can be enforced by broadcasting by signaling to the blockchain that party A should have their balance increased by X and B should have it decreased by X. This solution is ambitious but extremely complex. It will take considerable time and effort to test and eventually deploy such a solution. This is not to say that it is not viable, only that something is still needed in the short term to address the capacity problems.

Modeling Social Benefit of Proposed Solutions

The net social benefit to increasing the network’s transaction capacity can be modeled. As mentioned earlier, the network can currently handle about 3.5 transaction per second at best before the memory pool begins to fill. Examinations of recent periods where, in recent months, the network has crossed above this rate, and stayed above it for more than a few blocks show that transaction fees rise substantially.

figure 1

Figure 1 shows point Y, where user demand is the 1,800 per block and an average fee of .0003btc. Line S1 shows the supply of miners available at a 1MB. Line S2 is the rightward shift of S1, showing the transaction capacity with a 2MB block limit. Line D1 shows the demand for transactions processing at 1,800 per block. As bitcoin grows in usage demand is shifting rightward to line D3 where users demand 3,500 transaction per block, yet as shown in point F only 2,000 transaction can be handled and shortage is created, this can be seen as the supply becomes vertical — -in effect hitting a wall at 2,000 transactions. Miners gain all social surplus at quantities beyond 2,000 transactions. However at point M the gains to both miner and user are shared and the net benefit to both groups exceeds that at point F. In summation, both groups are better off if miners are permitted to move to S2.

The net gain in social benefit demonstrates that both users and miners would benefit from additional throughput capacity. For this reason the block size hard limit should be raised to 2MB to accommodate additional capacity in the short to medium term. 2MB is small enough that miners can still effectively share discovery of 2MB blocks without miners being disadvantaged by latency. Further, raising the limit now does not mean that the limit will have to be continually raised (nor should it). But this change would demonstrate to current and potential users that bitcoin can adapt to changing needs. Additionally, other virtual currencies have gained in popularity and if users can send $100 across nations for $0.20 or $1.00, they are going to migrate to the currency that allows remittance at a fee of $0.20 (all else constant). For Bitcoin to have a viable future both the block size limit needs to be raised and, to give it time to be tested and deployed most effectively, the Lightning network needs to be added.

Works Cited
Bohme, Chrsitin, Edelman, & Moore. (2015). Bitcoin: Economics, Technology and Governance. Journal of Economic Perspectives, 213–238.

Croman, D. E. (2016). On Scaling Decentralized Blockchains. IC3, 1–20.

Eyal, G. G. (2016). Bitcoin-NG: A Scalable Blockchain Protocol. Cornell University arXiv.

Kasahara, & Kawahara. (2016). Priority Mechanism of Bitcoin and Its Effect on Transaction-Confirmation Process. Cornell University arXiv.

Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off Chain Instant Payments.

Robla, E. (2015). Analysis of Reward Strategy and Transaction Selection in Bitcoin Block Generation. Thesis Paper, 16–38.

Turpin, J. (2014). Bitcoin: The Economic Case for a Global, Virtual Currency Operating in an Unexplored Legal Framework. Indiana Journal of Global Legal Studies, 335–368.

Acknowledgements: Dr. Mike Gumpper for help with building the social benefit models