Why We Must Increase the Block Size and Why I Support Bitcoin Unlimited ViaBTC Follow Oct 12, 2016 · 8 min read

This article was originally published in Chinese on my personal blog.

On October 10th, 2016, right after the conclusion of Scaling Bitcoin Milan (the third in a series of conferences on the topic of scaling the Bitcoin network), I made the decision to switch the bitcoin client software that ViaBTC runs from Bitcoin Core to Bitcoin Unlimited. This decision was not made lightly; I do not believe I have the right to impose my own personal views on the users of my pool. But, after consulting with all of the larger users on my pool I was able to make this decision with their overwhelming support.

The decision of whether or not to increase the block size beyond 1MB is ultimately made by the miners, but in the specific case of this issue, it is actually the pool owners, not the hardware operators, who have the experience required to make such a decision. As we are seeing now, and have seen in the past, it turns out that the miners (that is, those who own the hardware) do not actually care enough one way or another to cast a vote about making changes to the bitcoin protocol. It is my belief that the decision of which software to run is the responsibility of the mining pools and that waiting for the miners or the bitcoin developers to decide the course of action for the network is incorrect.

Currently, ViaBTC is signalling a vote for 2MB blocks in the coinbase of the blocks we mine, although we will continue to produce blocks with a maximum size of 1MB so as to follow what is currently accepted by Nakamoto consensus to be the rules of the bitcoin network. Based on tests we have run, we know that the network is entirely capable of handling 2MB blocks with no noticeable performance decrease, which is to say that the fears about an increase to 2MB blocks can be put to rest. The initial change to support larger blocks will require a hard fork. However, the switch to Bitcoin Unlimited is good for the long term health of the network, since it brings finality and eliminates any future need to use either soft or hard forks to alter the block size.

I also intentionally disabled Bitcoin Unlimited’s default signalling for BIP109 because we do not believe that BIP109 is the correct solution towards changing the block size. I hope that the developers of Bitcoin Unlimited can remove BIP109 as a default setting from their client software and avoid any future misunderstandings.

From the moment ViaBTC mined our first Bitcoin Unlimited block there has been an overwhelmingly large reaction from within the bitcoin community: most have been supportive; but there has also been controversy and plenty of conjecture. So, I feel that it is necessary for me to write about my decision in order to clear up some of the many misconceptions I see as well as to further explain my point of view.

Why bitcoin needs bigger blocks

Very simply put: if the block size is not increased then bitcoin’s growth will have halted at the level of adoption it is at today and bitcoin may as well be considered a failed experiment. That’s not to say that cryptocurrency itself would be a failed experiment. There will certainly be other cryptocurrencies capable of capitalizing on the growing user demand that bitcoin is currently incapable of meeting. Bitcoin is still in its earliest stages of development. Although we have seen incredible growth and adoption over the previous eight years, there is a long way yet to go. However, bitcoin has currently hit a wall regarding its growth and new user acquisition. This barrier is explicitly imposed by the artificial 1MB block size constraint. In my eyes, this refusal to evolve is no different than network suicide.

The gradually increasing transaction fees required to send bitcoin are unacceptable and will drive users to other cryptocurrencies that allow them to transact cheaply. This departure of users from the bitcoin ecosystem is a fatal blow to our development as a community. This is not conjecture — this is the current state of bitcoin. Another aspect continually overlooked by those who oppose an increase to the block size is that without growing capacity for on-chain transactions the business model of the miners who secure the bitcoin network against attacks will be destroyed. If mining ceases to be a profitable enterprise, and it will if we do not allow conditions which enable more on-chain transactions to occur, the network will lose the enormous amount of computing power that keeps it secure from attackers. This is guaranteed to bring about the failure of Bitcoin the protocol as well as bitcoin the currency.

Why Segregated Witness is a bad idea

An often repeated talking point is that the introduction of Segregated Witness will provide greater security and an effective block size increase to 1.7MB and therefore should be supported. This is missing the forest for the trees. An “effective increase” to 1.7MB merely delays the death of bitcoin, entirely misses the point of scaling, and fails to solve the fundamental issue at hand. The activation of SegWit on the network does not mean that all users of bitcoin will immediately be able to take advantage of its benefits since it will require at least a year for the “effective block size” to increase to 1.7MB. This does little to alleviate the current congestion on the blockchain. Furthermore, the introduction of Segregated Witness brings with it an enormous amount of technical debt which would require fundamentally altering the structure of bitcoin transactions and requiring all nodes, mining pools, block explorers, wallets, bitcoin ATMs, exchanges and other applications to do a complete refactoring of their software. The massive externalized costs of implementing Segregated Witness far outweigh the cost of performing a hard fork — and all of this for a mere 0.7MB “effective” increase in block size. Let’s not forget that Bitcoin Core’s insistence on SegWit was intended as a measure to avoid using a hard fork to increase the transaction capacity of the bitcoin network. SegWit activation will enable Bitcoin Core to keep refusing an actual block size increase and bitcoin’s death march will continue.

Why Lightning Network is not a sufficient scaling solution

First of all, the actual use cases for Lightning Network are fairly limited. Ask yourself why people use bitcoin: is it because they want fast confirmation times; or, is it because they want to use a decentralized money that is not controlled by any one organization? Bitcoin trades off speed and resource efficiency for resilience and safety, and bitcoin’s “slow” confirmation times are not in any sense problematic. Secondly, to characterize bitcoin transactions on the Lightning Network as “bitcoin transactions” is false: they are only bitcoin transactions in the sense that an exchange altering balances in its internal database is making “bitcoin transactions.” Deploying the Lightning Network, in fact, makes consumer use of bitcoin even more of a hassle. The deployment of the Lightning Network will lead to the creation of centralized hubs, where users will be required to lock-up their coins within these hubs in order to have them available for transactions. This differs only slightly from the current banking system from which bitcoin was meant to be an escape. Finally, the notion that bitcoin should be a “settlement layer” is ridiculous. Bitcoin is first and foremost a digital currency; its settlement capabilities are secondary to its monetary properties. When bitcoin loses its monetary attributes it thereby loses all utility as a settlement network. To be clear, the Lightning Network is a fine innovation but to say that it will become the primary method of transacting small amounts of bitcoin is patently absurd.

Why I support Bitcoin Unlimited

As a community, we have wasted years debating the ultimately trivial technical question of block size. It is time to implement a positive solution, once and for all, to resolve the question of block size limits. To hard-code on the protocol level whether blocks should be large or small is fruitless and will lead to even more conflicts down the road. We should give the question of block size to the free market to decide. It will naturally adjust to be in pace with ever-improving network and technological constraints. Bitcoin Unlimited’s decision to hand over a block size limit setting to the miners guarantees that block size will follow what the bitcoin network is capable of handling safely. Bitcoin Unlimited allows miners to set both the maximum block size they will produce and the maximum size they are willing to accept, with both signals included in the coinbase scripts of each block. If a node discovers that a chain with larger blocks is already four blocks (the default setting) ahead of the chain it is currently on, it will automatically switch and acknowledge this longer chain as the valid one in accordance with Nakamoto consensus rules. This makes future block size adjustments easy and prevents this issue from ever becoming as contentious as it has been for the previous two years.

Why a hard fork poses no threat

The greatest danger of a hard fork, it is said, is that it will produce a scenario in which there are two blockchains and thus two different versions of bitcoin. But as far as I can tell, in the scalability debate, the vast majority agree that block size needs to grow sooner or later while the main difference of opinion is over the method used to achieve this. The reason the recent Ethereum hard fork produced two different versions of Ethereum was because a fundamental quality of the ledger, namely its immutability, was permanently changed. Furthermore, because bitcoin’s difficulty adjustment period is two weeks long, with ten minutes per block, whichever branch of the chain has the majority of hashrate behind it is almost certainly guaranteed to be the decisive winner; the chances of a fork producing two different bitcoins are low. The minority-chain will have much slower block production times, and rational miners will switch to the majority-chain to avoid mining at a loss. The only rational choice for a miner will be to join the chain supported by the economic majority.

How the hard fork should be implemented

As Bitcoin Unlimited is written, there is no set threshold at which a hard fork is initiated. In theory, a hard fork can be initiated any time a majority of hashrate is in agreement. Done improperly this is dangerous and is not a meaningful way to make protocol changes. With Bitcoin Unlimited, a miner majority is required to decide together that a hard fork will happen. Only then will miners come to an agreement on the hard fork activation date.

First, under what circumstances should a hard fork be initiated? I recommend following Bitcoin Classic’s 75% threshold. In other words, a hardfork will be initiated only after more than 75% of the network hashrate is supporting Bitcoin Unlimited. If the consensus threshold is set too high then reaching consensus will be unattainable, as a single determined mining pool could veto a change for the entire network. A 75% threshold is perfectly adequate to perform a hard fork safely.

Secondly, how do we decide the timing of the hard fork? My recommendation is that the fork be performed at least one month after the 75% activation threshold is reached. This will give the community ample time to upgrade their node software in preparation. The fork should be timed so that it occurs immediately after a network difficulty adjustment. This makes it economically unfeasible to remain on the minority chain and eliminates the risk of a “two bitcoins” situation arising. This is Nakamoto consensus working as intended.

Conclusion

My assessment of the various scaling proposals put forth by Bitcoin Core and Blockstream at Scaling Bitcoin Milan is that they all seem to “cut off the nose to spite the face”. For reasons that remain unclear to me they want to destroy the unique monetary properties of bitcoin and destroy the business model of the miners who secure the bitcoin network. The interests of bitcoin miners and everyday users are strongly aligned. By working together and identifying common interests we can bring about a renaissance in Bitcoin and bring mutual benefit to all parties involved. By working together as a united community of developers, miners, users, and businesses, we can demonstrate to the world that the bitcoin network can be adaptive, anti-fragile, and resistant to centralization.