Beginner’s Guide to Bitcoin’s Scalability Debate

By Kevin Huynh and Steven Chen

Bitcoin, a pioneering cryptocurrency invented in 2008 by Satoshi Nakamoto, was a first-of-its-kind technological advancement. Today, at over $50B valuation, it remains the dominant cryptocurrency, proving time and time again its resilience to government regulation, bans, and hackers. More importantly, bitcoin has made “distributed ledger technology”a new field of research and development. What bitcoin has brought to the hearts and minds of successive visionaries and entrepreneurs is electrifying. What was once a single organism now flourishes within a rapidly growing crypto ecosystem.

As the vision and adoption of decentralized assets grow, however, bitcoin struggles to keep its technological lead: scalability is a formidable growing pain. The Bitcoin network’s throughput maxes around three transactions per second (TPS) — far below the throughput of current dominant payment systems. As a benchmark, bitcoin’s current throughput pales in comparison to the Visa network’s ~2,000 TPS. In this article, we discuss at a high level the key areas of contention — variables of and innovations atop Nakamoto’s protocol that can be flexed to alter the Bitcoin network’s performance. We summarize Segregated Witness, the Lightning Network, protocol adjustments, and how each alone has its shortcomings.

Segregated Witness (SegWit) is a modification to the original Bitcoin protocol. In theory, it can double bitcoin’s throughput to approximately six TPS. In short, SegWit increases transaction throughput by re-weighting the signatures of transaction data to allow more transactions to fit within each block. (For more detail, this article explains how.) While any improvement is welcomed, this theoretical doubling of transaction throughput remains too low for mainstream use of bitcoin as a payment system. While some believe that bitcoin need only serve as a store of value and suggest that transaction throughput is of lesser importance, many stakeholders have argued that moderately higher performance beyond that of today is necessary to achieve mainstream adoption. Does the global trade in gold, the quintessential store of value, top out at less than six transactions per second? The SegWit-driven throughput improvement alone is still insufficient, even for a store of value. What else then can be done to improve the situation?

The current bitcoin saga à la hard fork brings another blockchain innovation back into the spotlight: the Lightning Network (LN). If SegWit activates as expected, the LN can be implemented on top of the existing Bitcoin network, thanks to SegWit solving the problem of transaction malleability. In short, payment channels, which are the fundamental building block of the LN, allow users to “lock up” their bitcoins (for clarity: transactions occurring on the underlying protocol are called on-chain, layer one, or “L1”) and transact with chosen parties off the Bitcoin network (a.k.a. off-chain, layer two, or “L2”). LN allows small transactions by allowing many transactions to be sent over the lifetime of payment channel, which requires only two transactions, one to open and one to close. The LN is a network of payment channels, allowing users to transact with anyone on the network, even if a direct payment channel does not exist. LN transactions can be considered final immediately, without the need for one or more block confirmations. LN payments can be significantly faster than those on-chain, as they negate the need for six blocks of inclusion (the de-facto standard for rubber stamping an on-chain transaction as valid and secure, which often take one or more hours to achieve). Instead, LN payments are virtually instant as LN confirmations are derived from blocks mined on top of layer one. Furthermore, layer two solutions can potentially support applications such as Tumblebit for privacy, state channels and many more innovation opportunities for bitcoin.

By design, the size of any LN transaction is limited by the capacity of the smallest payment channel along a LN payment route. Therefore, LN can take small transaction value use cases off-chain to free up bandwidth on-chain. How is this useful? Consider the futurist experience of buying consumables with cryptocurrency: will you pay on-chain and pay fees that cost more than your coffee and wait at the counter for a block to be mined that includes your transaction? LN can overcome these two issues. However, LN alone does not address the scalability issue for large on-chain payments or use cases where transactions do not or cannot use the LN.

Another proposal to improve bitcoin’s scalability on-chain is to increase the block size. The idea is superficially simple: increasing the block size from today’s 1 MB to, for example, 8 MB would increase transaction throughput eight-fold. Hence, can we just increase block size further and further and ride off into the sunset happily together?

Unfortunately, it is more complicated than that. Increasing the block size would decrease the security of the network to some extent due to the decrease of effective honest hash power. How so? Consider that an important rule of the Bitcoin Protocol is that the longest chain will always be recognized as the main chain, upon which successive blocks are built. Well, what happens in the canonical attack vector known as the double-spending attack? A bad actor would pay a merchant while mining himself a malicious chain that does not include this payment. The global network may be tricked into recognizing the malicious chain as the main chain, effectively erasing his transaction to the merchant from the ledger.

How is that example attack related to not being able to increase block size to scale bitcoin scalability? (See bottom of article for more expanded discussion of this attack.*) Block size is intimately related to the propagation time needed for a newly mined block to be seen by all nodes in the network. On the current network, whose blocks are 1 MB, the mean time for a node to see a newly created block is roughly 12.6 seconds. During this window of time, it is often the case that one node broadcasts the creation of its new block while another node, one that may be across the world, also broadcasts its own newly created block. Eventually, one of these two blocks will get dropped from the network due to the network recognizing only one as the longest chain known as chain reorganization. This dropped “stale block” may have tried to validate many honest transactions, but still gets dropped by the network. In the smaller block scenario, chain reorganization rids of fewer honest transactions than in the case of larger blocks. As greater block time means more transactions were incorporated into the block. Furthermore, the hash rate contributed to the mining of larger stale blocks will be greater than in smaller blocks, further increasing the inefficiency that exists in securing today’s Bitcoin network. In other words, the larger the block size — and the longer the propagation time — results in more hashrate not contributing to network security dedicated to blocks that actually make their way into the blockchain.

One might also ask, “if we can’t increase block size, can’t we just decrease the block time to increase transaction throughput?” For bitcoin to operate correctly, propagation time must be negligible relative to the time it takes to mine a new block. Decreasing the block time would lead to a decrease in security of the Bitcoin protocol; in an extreme scenario, if the block time were to be decreased to one second, and since propagation time is approximately 12 seconds, mining nodes would not have seen the latest block, and would continue to mine on top of a stale block. Mining nodes would be mining blindly, causing a significant amount of the network hashrate to be wasted, leading to the exact same outcome as increasing the block size as explained earlier.

You may, like us, find that the different scaling options discussed above lacking, despite being debated vehemently within the Bitcoin community. Whether through not sufficiently addressing layer one scaling (in the case of SegWit and LN) or having significant drawbacks (in the case of block size increases and propagation time), the Bitcoin network requires further fundamental improvements to meaningfully increase scalability. In our next article, we will discuss promising layer-one scaling solutions. These technologies can be applied to bitcoin through forks or power brand new ledgers that aim to achieve throughput levels supportive of real world use-cases.

If this article was informative for you, please follow me on Twitter and my firm, Norís, on Linkedin.

Disclaimer: The content published in no way constitutes an investment recommendation by Norís.

We thank Casey Rodarmor, Bitcoin Core Developer, for contributing his technical expertise and editorial skills to this publication.

* Continuing double spend attack explanation: some conditions need to be met for this attack to work. The attacker needs to be rather lucky in order to temporarily form a longer blockchain than the honest chain. It becomes less and less probable for this attack to work as stakeholders require higher numbers of block confirmations to be deemed secure. The more confirmations, the more time the attacker needs to spend attacking the blockchain, which both increases cost and decreases probability of a successful attack. It has been calculated that if an attacker possesses 10% of the network hash rate, the probability of success to double spend under six confirmations is ~0.1%. It is not economically efficient to even attempt this because the attacker would have essentially missed out on 10% of the block rewards and transaction fees (assuming uniform distribution).

The story is different if an attacker somehow possesses 51% or more of the network’s hash rate. In this case, regardless of the number of confirmations, the attacker will have a 100% chance to double spend. The reason for this is because the attacker will always be able to successfully create a longer chain in private, ready to broadcast to the network at any time. It is unlikely this attack will occur in the Bitcoin network as there isn’t a single mining pool with close to 50% of the network hash rate.