Former Bitcoin Core lead maintainer Gavin Andresen’s Bitcoin Improvement Proposal (BIP) 101, which brought Bitcoin’s scaling debate to a new level when it was implemented in Bitcoin XT, is now almost two years old, but no solution for increasing Bitcoin’s on-chain throughput has been adopted.

The two proposals for increasing on-chain throughput in Bitcoin with the loudest public support at this time are Bitcoin Core’s Segregated Witness (SegWit) and Bitcoin Unlimited’s Emergent Consensus (EC). Prominent members of the Bitcoin community have been searching for a compromise between these two proposals, but such a solution to the current debate may be misguided and unable to work.

What is the Goal?

Before coming to consensus on a solution, the Bitcoin community must come to consensus on the problem. What are proposals such as SegWit or a hard-forking increase to the block size limit supposed to achieve? What is the goal?

Obviously, everyone would like to see bitcoin used as often and cheaply as possible – both as a store of value and a medium of exchange. In a perfect world, there would be no tradeoffs involved with increasing the block size limit to 1 gigabyte and increase Bitcoin’s on-chain transaction capacity a thousandfold overnight, but that’s not how this works.

There are tradeoffs involved with increasing the cost of operating a full node. When users are unable to run full nodes, their say in Bitcoin’s consensus rules decline.

In other words, the goal of any scaling proposal is to increase bitcoin’s usefulness as a store of value and medium of exchange safely without negatively affecting bitcoin’s core value proposition, which is as a bearer ecash.

What are the Proposals?

There have been quite a few proposals regarding changes to Bitcoin’s block size limit made over the years, but the two that have the largest amount of attention right now are SegWit and EC.

SegWit is a proposal that would increase the effective block size limit in Bitcoin to a little over 2MB via a soft fork, in addition to fixing transaction malleability (thus improving layer-two protocols such as TumbleBit and the Lightning Network) and providing a an improved process for future upgrades to Bitcoin’s scripting system. A full list of the benefits of SegWit can be found here.

EC is the idea that the block size limit should be configured by miners and users via their full nodes instead of having a hard-coded limit in the protocol. The initial increase of the block size limit over 1MB would cause a hard fork, while users and miners will need to make sure their nodes are properly synced with each other in the future to make sure they remain on the “correct” chain.

Why a Compromise May Not Work

With the aforementioned goals in mind, the Bitcoin community can take a look at each proposal to figure out which one contains the best tradeoffs in terms of increasing on-chain throughput while also maintaining bitcoin’s core value proposition.

Currently, SegWit has the support of every major wallet provider in the Bitcoin ecosystem. EC is much less popular, but there is definitely a large chunk of the community who would like to see some kind of hard-forking increase the block size limit implemented.

Just because someone is in favor of a hard-forking increase to the block size limit does not mean they are in favor of EC. A recent poll of “blockchain personalities” conducted by 21 found that 49 percent of respondents were in favor of a hard-forking increase to the block size limit, while only 23 percent supported the concept of EC. 75 percent of respondents were in favor of activating SegWit.

Recently, ShapeShift CEO Erik Voorhees offered a combination of SegWit with a hard-forking increase of the base Bitcoin block size limit to 2MB as a suggested compromise between these two camps on The Crypto Show.

The currently available research on Bitcoin’s block size limit suggests an increase to 4MB could lead to 10 percent of the full nodes on the network dropping off. SegWit enables a 4MB block size limit in adversarial conditions. If a hard-forking increase to Bitcoin’s base block size limit is also added to the protocol through a compromise, this would effectively increase Bitcoin’s block size limit to roughly 8MB.

It should be noted that one of the co-authors of the previously linked research, Cornell’s Emin Gün Sirer, recently clarified that “the 4MB size suggested in that paper should not be used without compensation for two important changes to the network.” Sirer was referring to the measured speed of the P2P network and the emergence of high-speed block relay networks.

Having said that, no further research on acceptable block size limits for Bitcoin has been made available. The availability of such research could impact the level of support for various scaling proposals.

Combining a hard-forking block size limit increase with SegWit may actually be more controversial than SegWit by itself because some initial supporters of SegWit will be turned off by the increase of the effective block size limit from 4MB to 8 MB and the fact that the increase of the base limit requires a hard fork, which is not backwards compatible (unlike a soft fork).

Additionally, a hard-forking increase of the block size limit to 4MB without SegWit may not gain support because it does not come with improvements for TumbleBit and the Lightning Network that are enabled by SegWit’s fix for transaction malleability, in addition to the other benefits of the proposal. And again, such a change would require a hard fork.

There is a main area of disagreement when it comes to hard forks and soft forks in general. A compromise between these two methods of upgrading the Bitcoin protocol is simply not possible, unless some new type of fork is developed and agreed upon by the community.

Instead of a compromise, each technical solution to increasing bitcoin’s usefulness as a medium of exchange and store of value should be taken on its own merits. A compromise would only lead to a less technically sound solution.

“The sole objective of this proposal is to re-unite the Bitcoin community and avoid a cryptocurrency split,” RSK Chief Scientist Sergio Lerner recently wrote to the Bitcoin development mailing list regarding a combination of SegWit with a hard-forking increase of the block size limit to 2MB. “[This proposal] does not aim to be best possible technical solution to solve Bitcoin technical limitations.”

#Bitcoin by design makes it much easier to block consensus rule change than to force it. This is an important feature, not a bug. — Eric Lombrozo (@eric_lombrozo) March 31, 2017

The history of Bitcoin’s scaling debate up to this point has shown that, at this point, only changes that are nearly universally agreed upon will be made to the protocol – especially when it comes to hard forks. In other words, hard-forking increases to the block size limit are likely to lag behind even what the majority would like to see implemented.

In Bitcoin a compromise means sticking with the status quo, not implementing a combination of two different, mostly unrelated proposals.

This isn’t to say that SegWit and a hard-forking increase to the block size limit won’t both be implemented at some point; rather, it’s to say that they won’t be lumped together in a proposal to have them both activated at the same time in some sort of “official” compromise.

These proposals will be viewed separately and implemented when there is consensus around each option on an individual basis. There is no need for a compromise at all. Each solution can be implemented as it gains consensus. One being implemented does not preclude the other from also being implemented eventually.

It’s possible that users will decide to implement an upgrade that is somewhat contentious at a point when doing nothing seems to be worse than the risks associated with a contentious upgrade. Another possibility is a new proposal, such as a sidechain or an extension block with a much larger block size limit, coming along that is able to gain more support from the community.

Image adapted from BTC Keychain/Flickr.