Fixing Bitcoin’s Scalability Problem: From Hard Forks to The Lightning Network

In order to avoid attacks on the network, Bitcoin was built with a maximum block size of one megabyte. This limited the total amount of transactions which a block could contain. Throughout the history of BTC, backlogs on the network have been common. Users have had to wait extended periods of time or pay high fees to confirm transactions on the network. Initially, hard forks of the Bitcoin Core software client were attempted followed by forks of the Bitcoin blockchain to increase the block size. This has not proven successful. Another attempt at increasing scalability, however, has emerged using SegWit and the Lightning Network. Doing this allows sidechain payment channels to be used to minimize the total number of transactions which take place on the main Bitcoin blockchain (mainnet). Furthermore, a number of uses for the network which might accelerate mass adoption and social integration have been proposed and developed.

Bitcoin Core and Beyond

Bitcoin Core is the software protocol which acts as the basis of the distributed ledger technology which makes the Bitcoin blockchain function according to the proposal defined by Satoshi Nakamoto in Bitcoin’s white paper released in 2008. Core includes updated information about the Bitcoin decentralized network and is distributed to all users on the network. In other words, every time a block is added to the blockchain, Core reflects that change. There is no centralized location in which amended versions of the blockchain are saved. Instead, all changes to the BTC blockchain are recorded across a distributed network in which universal access to the blockchain via Core is made possible. Furthermore, the software provides a bitcoin wallet which verifies sending, receiving and storage of bitcoins. Many other bitcoin wallets are also integrated with Core. Several hard forks have been attempted on the Core by changing its initial protocol. Often, the forks include changes that allow block sizes larger than 1 megabyte (mb). If adopted by a large enough number of miners, servers, wallets, users, or others, these forks could displace the dominance of Core. None, however, have been able to do so.

Failed Hard Forks of Core

Bitcoin XT was one of the earliest attempted hard forks of Bitcoin Core. It was initially released on Aug 15, 2015, with the intention of increasing the block size to 8 mbs. This would have allowed more transactions within each block and increased the overall number of transactions which could occur per second. Bottlenecks, high fees, and long waits, theoretically could have been alleviated with the successful adoption of XT over Core. However, despite initial hype, XT did not maintain long-term miner support. Thus, Core remained the primary software protocol for the Bitcoin network. Other forks were later attempted. Bitcoin Unlimited was initially released several months after XT. Between Feb and May 2017, Unlimited faced at least four major issues including bugs, memory leaks, and servers going offline. Needless to say, Unlimited, like XT, has failed to replace Core. Furthermore, Bitcoin Classic, initially released in Feb 2016, attempted to do what XT had failed but with greater modesty. Instead of increasing the block size to 8 mbs, Classic would have only doubled the block size from 1 mb to 2 mbs. Similar to XT, it also received a lot of early hype among miners but failed to garner enough support to replace Core as the dominant software protocol for the BTC network. By Nov 2017, Classic had ceased operations. Bitcoin Core remains the primary software protocol for the Bitcoin network. No suggested, theorized, or attempted fork of the software has been successful.

Bitcoin Cash

With the failure of hard forks to Core, another way to fork Bitcoin emerged. Instead of changing the software itself, the Bitcoin blockchain would be forked to create a new cryptocurrency. For instance, the first successful BTC hard fork was Bitcoin Cash (BCH) which occurred on Aug 1, 2017, at Bitcoin block 478,559. At this point, BTC continued on its own blockchain while BCH emerged as a new blockchain. BCH successfully increased the block size to 8 mbs as XT had attempted while allowing the original BTC with 1 mb blocks to continue existing. One problem with such hard forks is that they are prone to divide a cryptocurrency’s community into warring parties. If everyone agrees to use the new crypto, then a non-contentious hard fork occurs. This is, however, not always the case. While some people might support the changes a hard fork proposes, others do not. This was the case with the BTC hard fork. Not everyone agreed in the changes that BCH proposed, just as not everyone agreed with XT. A contentious hard fork occurred with BCH in which the once united BTC following was now divided into two camps, each supporting a different cryptocurrency.

Bitcoin Cash Civil War

A non-contentious hard fork of BCH took place in May 2018 when the block size was increased from 8 mbs to 32 mbs. On Aug 16, 2018, however, the BCH Civil War began when Jimmy Nguyen proposed Bitcoin SV as a hard fork of BCH. The fork included a number of changes to BCH including the increase of the block size to 128 mb. In opposition, Roger Ver and others announced Bitcoin ABC, which included less significant changes to BCH than SV. On Nov 15, 2018, BCH forked into SV and ABC. For a period, both competed over which would be the ‘real BCH.’ Currently, it appears that ABC has won as it is listed on most major exchanges as BCH while Bitcoin SV (BSV) is listed as its own crypto. As of 5:24 PM EST, BCH was ranked with the fifth highest market cap, while BSV, is ranked tenth.

Bitcoin Private

Many other hard forks followed Bitcoin Cash. Most were fairly unremarkable and have been all but forgotten.

Bitcoin has had a few forks since 2014, some of which you won't even remeber. We've compiled a nice graph to illustrate all of them. pic.twitter.com/yBQh4VDeJJ

— DataLight (@DataLightMe) January 29, 2019

Bitcoin Private (BTCP), however, was novel in its attempt to merge two cryptocurrencies together during a simultaneous hard fork. On Feb 28, 2018, BTCP emerged when BTC block 511,346 and ZCL block 272,991 hard forked. The two blockchains that would have been created as a result of these forks merged into one blockchain. BTCP was born. There were a number of purposes for this ‘merge fork’ including:

• Increasing the security of BTC by integrating ZK-snarks from ZCL
• Allowing private transactions between users using shielded addressed inherited from ZCL
• Solving the scalability problem by increasing BTC block size to 2 mbs
• Changing the Proof-of-Work mining algorithm to make it ASIC resistant

BTCP Failure

In short, BTCP was meant to be a more secure version of BTC with larger block sizes and increased opportunities for mining by general users rather than industrial mining rigs and centralized pools. The BTCP hard fork, however, was less successful than anticipated. In Dec 2018, Coinmetrics discovered more BTCP coins in supply than there should have been. Based on further research, it was discovered that a bad actor fraudulently created a pre-mine of coins during the merge fork of ZCL and BTC. As a result of this fork, over two million BTCP was created that should not have ever existed. Only around 1.7 million of the over 2 million could be discovered. At least 300,000 appear to have been sold leading to possible millions in profits for the bad actor. BTCP attempted to correct for this by deleting the fraudulent BTCP with a hard fork on Jan 5, 2019. Despite, the successful hard fork following the merge fork, these lost BTCP are likely never to be found. The hard fork, a supposed solution, solved only part of the problem.

SegWit the Soft Fork

Instead of increasing the block size, another approach has been attempted. One of these includes a soft fork called SegWit. Soft forks, rather than hard forks are backwards compatible. This means that while they change the protocol of the blockchain moving forward, these changes do not alter the fundamental protocol in the way a hard fork does. It is because hard forks create changes that are not compatible with the original blockchain that they are required at all. For example, to allow the features of BCH or BCTP to be fully experienced requires a whole new blockchain because the features of both cannot be made compatible with the original design of BTC. SegWit stands for segregated witness and allows side-chains to be built on top of the Bitcoin blockchain. Using these side-chains, payment channels can be created which allow multiple transfers from one party to another using bitcoins without making the transactions on the Bitcoin network. This is the first part of the Lightning Network.

Using the Lightning Network

If Jack wants to buy a cup of coffee from a coffee shop that accepts Bitcoin, he can create a private payment channel with the coffee using the Lightning Network. A transaction occurs when the payment channel is opened, and Jack and the coffee shop deposit an undetermined amount of bitcoins into it. The coffee shop may likely deposit zero bitcoins since it is the seller while Jack may deposit enough money to buy 10 cups of coffee. Every time he buys coffee after the payment channel is set up, all transactions between him and the coffee shop will take place across it. None of these occur on the mainnet. Instead, they are attached together as one transaction and later attached to the mainnet, likely when Jack has used all of his funds. If 10 cups of coffee are purchased 10 times, then 12 transactions that would have taken place on the mainnet can be minimized to two. The first transaction creates the payment channel, a second hashes the total transactions back onto the mainnet as one transaction.

Increasing Use-Value of the Lightning Network

Instead of increasing the block size with contentious hard forks, SegWit and the Lightning Network minimize the number of total transactions on the blockchain between two parties. Furthermore, it connects parties through other parties to reduce the need for transactions. For example, if Jill wants to buy a coffee at the coffee shop but does not have a payment channel set up, she can pay through Jack as long as she and Jack have a payment channel set up prior to the purchase. Essentially, as long as Jack as enough funds in his account, Jill will pay Jack who will then pay the coffee house. The funds will move from Jack through a payment channel to the coffee shop and then from Jill to Jack. George, likewise, could pay through Jill who pays through Jack if George and Jill have a payment channel open between each other and George does not have a payment channel open with Jack. However, if George has a payment channel open with both Jack and Jill, then the Lightning Network will choose the shortest route for the funds to travel to get to their destination. Instead of going through Jill and then through Jack to get to the coffee shop, they will go from George through Jack to the coffee shop. In the former situation, there are two intermediaries (Jill and Jack). In the second, Jack is the only intermediary. Whenever a transaction occurs between two parties, the Lightning Network attempts to limit the total number of intermediaries.

Conclusion

As of Jan 26, a number of uses for the Lightning Network have been deployed using various sources. A text file sharing service, for example, was created using the Blockstream Satellite Client using the Lightning Network. Furthermore, point-of-sales systems, e-commerce interfaces, and paywalls integrated with WordPress have been developed using the BTCPay Plugin developed as part of BTCPay Secure. While hard forks have created great contention, divided once united cryptocurrency communities, and done little to displace BTC dominance, the Lightning Network is beginning to appear as the most plausible route toward solving the problem of scalability. Do you think the Lightning Network is a better solution to the problem of scalability than hard forks? Let us know your thoughts in the comments below! 

---