Bitcoin’s Block Size Controversy is Morphing Into a Debate Between Hard Forks and Soft Forks

For nearly the past two years, various alternatives to Bitcoin Core have attempted to increase Bitcoin’s block size limit via hard-forking changes to the codebase run by nodes on the network. While manageable capacity increases are desired by many Bitcoin users, the complications associated with hard forks have left the network unwilling to adopt an increase to the block size limit.

A hard fork requires every economically-relevant Bitcoin full node (or at least nearly all of them) to upgrade to a new network, while a soft-forking change is backwards compatible. As illustrated by Ethereum’s hard fork to bailout DAO token holders, contentious hard forks can be difficult to pull off.

Of course, a sufficiently contentious soft fork could also lead to users hard forking away from the current group of miners in an effort to opt-out of that particular version of Bitcoin, which could potentially lead to two different versions of Bitcoin continuing to exist (similar to what is currently seen with Ethereum and Ethereum Classic).

Before going further into this article, it should be noted that the ongoing debate is not between people who always prefer hard forks and those who always prefer soft forks. Instead, the debate is over preference. The proposed Segregated Witness (SegWit) upgrade has turned into the perfect illustration of this debate, as some would prefer to see it as a hard fork rather than a soft fork.

Increasing the Block Size Limit via a Soft Fork

Although still not a widely known fact, the reality is that there is a large amount of flexibility offered to the Bitcoin protocol by way of soft forks. While many would still like to see a hard-forking change to Bitcoin’s block size limit, methods of achieving capacity increases via soft forks have also been discovered over the years.

Bitcoin Core contributor Johnson Lau recently posted a BIP (Bitcoin Improvement Proposal) draft on the Bitcoin development mailing list, and the idea is to implement a soft-forking block size limit increase via extension blocks. This is not an entirely new idea, as multiple threads on the mailing list have discussed the concept in the past. Blockstream CEO Adam Back discussed the usefulness of this sort of idea publicly back in 2015.

According to Back, the recently released Segregated Witness improvement to Bitcoin is a sort of extension block. “SegWit is kind of a simplified extension block, where signatures only are in it,” he told CoinJournal. “With a full extension block, you put the whole transaction in it.”

While this sort of change still requires broad consensus among the community, it is more attractive to developers and investors who wish to avoid a hard fork, which they see as much more difficult to coordinate (due to the need for everyone to upgrade to a new network).

Extension blocks have been compared to sidechains due to their ability to extend the usefulness and functionality of Bitcoin by way of a soft fork.

While a sidechain is a separate blockchain and network, an extension block is more of an extension of the Bitcoin network itself. Transactions in extension blocks are validated by full nodes, which means there is no two-way peg mechanism necessary to send some bitcoin between the various sectors of the Bitcoin network.

A problem with sidechains and drivechains that is often pointed out is that a majority of miners can decide to steal bitcoins that are stored on the sidechain. While Bloq Economist and Bitcoin Hivemind creator Paul Sztorc believes his drivechains proposal mostly solves this problem, the issue does not exist with extension blocks because Bitcoin full nodes are validating both chains.

“Because everyone validates everything, of course they know [when] funds are locked or destroyed,” Johnson Lau told CoinJournal.

While extension blocks may prove to be useful for making simple tweaks to Bitcoin, both Back and Lau say they should not be used to enabled more experimental features. This is due to the negative effects a complex extension block could have on the security of the main chain.

“A sidechain is very independent, it’s a separate daemon, and has no consensus connection,” explained Back.

“Even an RSK-like side chain could be [an] extension block, but that means we are bringing the risks of RSK to bitcoin,” added Lau.

RSK is a complex smart contracting system currently being developed as a hybrid drivechain to Bitcoin. It has drawn comparisons to Ethereum.

In terms of Bitcoin’s block size debate, extension blocks and sidechains have the potential to give everyone what they want. Those who wish to stay with a 1MB block size limit don’t need to adopt the extension block, while those who would like to see an 8MB block size limit or higher can opt-in to the change.

What are the Arguments Against Soft Forks?

So if most upgrades can be made via soft forks, what is the argument for adding these sorts of improvements to Bitcoin via hard forks?

The arguments from those in favor of hard forks over soft forks in general usually revolve around two key topics: the avoidance of technical debt and the democratization of upgrade power from developers and miners to users. Having said that, there are also other arguments made in regard to specific, proposed changes such as Segregated Witness.

In terms of technical debt, the claim is that Segregated Witness and some other soft forks are ugly hacks that add unnecessary complexity to the codebase. The argument is that this complexity will make it harder for developers to work with Bitcoin’s codebase. A post on the Bitcoin Core website points out that one of the main intentions of the Segregated Witness improvement is to remove some technical debt that already exists, most notably transaction malleability.

An example of the added complexity that comes with Segregated Witness is that exchanges and wallet providers will need to keep track of two different transaction IDs, addressing paths, and more for each transaction if Segregated Witness is activated on the network (and they wish to implement the new features in their own software). “Ultimately, you don’t have a clean upgrade from A to B. You upgrade from A to a situation where you have A and B coexisting for months and years into the future,” explained Bloq CEO and former Bitcoin Core contributor Jeff Garzik during his presentation at an OnChain Scaling Conference last summer.

Related to the technical debt argument is that more complex code may open itself up to more risks via unforeseen bugs. That said, Segregated Witness was tested on three custom testnets and the main Bitcoin testnet before being released in a version of Bitcoin Core. Of course, no real money was on the line on these testnets.

Some have wondered whether Litecoin may act as an effective testnet for Bitcoin with real money on the line if Segregated Witness is activated on that cryptocurrency network first.

In terms of who decides what changes are rolled out via hard forks and soft forks, Garzik touched on the topic in an interview with Bitcoin Uncensored last year.

“That is the key, underlying parameter—being able to upgrade the system in a way that allows people to have a voice, to have a say, in that upgrade,” said Garzik in the Bitcoin Uncensored interview. “I support SegWit, [but] I think it would be far better as a hard fork because if you introduce changes in pricing [or] economics and you do that through a tiny set of people (a couple developers and a couple of miners), then that is really that antithesis of what Bitcoin was meant to be.”

In Garzik’s view, soft forks do not offer the proper balance of power between developers, nodes, miners, and the economy. Instead, protocol decisions are left to developers and miners.

“I think it’s a mistake to enoble a high-priesthood of Bitcoin and say, ‘Just these hallowed few will make decisions for everyone,’” Garzik added. “Also, I think it’s a mistake to assume technical experts are also economic experts . . . That’s not the Bitcoin we all bought into in 2010.”

It should be pointed out that users always have the option of rejecting a soft fork by hard forking away from miners. Users can also simply decide not to accept the soft-forking upgrade. After all, soft forks are “voluntary upgrades,” as Garzik referred to them during the same interview.

So if soft forks are also voluntary, then what’s the problem?

The key argument here is that, while soft forks are not mandatory from the perspective of users, they can still negatively affect users who do not upgrade. Specifically, non-upgraded nodes may operate with degraded security once a soft fork has activated. After all, the old nodes are not validating the new rules of the system.

This degraded level of security is why some see soft forks as coercive. Some Bitcoin Core contributors have also pointed out that soft forks can enter the territory of coerciveness, but the general consensus on Segregated Witness from these developers is that this particular upgrade does not cross that line.

In terms of the degraded security for old nodes after the activation of Segregated Witness, Bitcoin Core contributor Nicolas Dorier responded on Twitter, “A miner who is ready to [lose] 12.5 BTC can make a non-upgraded user [believe] he got 1 [confirmation] for 10 minutes.”

As Lau pointed out, accepting a 12.5 BTC payment based on one confirmation is always a bad idea due to risks associated with a natural blockchain reorganization.

A warning system is also outlined in BIP 9, which is the Bitcoin improvement proposal that outlines how soft forks are rolled out onto the network these days. The warning system tells full nodes about an unknown soft fork at least three weeks before activation.

A similar security tradeoff was made to activate BIP 16. “I think such [a] temporary degrade has been proven as acceptable,” Lau told CoinJournal.

During his interview on Bitcoin Uncensored, Garzik also pointed out that Segregated Witness does not enable predictable changes to block space economics because the block size limit will increase as individual wallet providers implement the upgrade rather than when the change is activated on the network.

While these issues with soft forks clearly merit discussion, it’s unclear if they outweigh the rather noteworthy benefits of backwards compatibility and allowing users to opt-in to changes on a voluntary basis; that’s the key question here.

The debate between hard forks and soft forks is a debate between the different tradeoffs involved with each mechanism for upgrades, and neither is perfect. Rather than finding the best option, it may be more about finding the “least worst” method of adding improvements to Bitcoin.