The blocksize debate: is an end in sight for the civil war that has engulfed Bitcoin?

Depending on which parts of the Internet you inhabit, your perception of what’s happening in Bitcoin land can vary hugely.

The Bitcoin community is bitterly divided. For years now it has been split into two camps, those who think Bitcoin needs an urgent blocksize increase, and those that think other scaling approaches should be prioritised.

The “big blockers” are worried that with the current limit of mostly full 1MB blocks, there isn’t enough capacity for Bitcoin to grow. They think this will cause real harm to Bitcoin’s network effect, and that not addressing it urgently could result in Bitcoin losing its position and momentum as #1 cryptocurrency.

Whether you see merit in this view or not, it’s important to recognise that to somebody who is convinced that failing to urgently raise the blocksize could lead to Bitcoin’s downfall, the current standoff and ongoing lack of an increase would be incredibly frustrating. It is understandable that frustration and helplessness would lead to a deep seated suspicion and contempt for those they see as standing in their way.

For those of you that don’t visit the big blockers communities, it’s staggering to see the vitriol and anger directed at those “progress preventers” the Bitcoin Core developers, the team that has long served as custodians of the main Bitcoin implementation.

While big blocker communities can feel a little bit like the front line of a war, frequenting the “small blocker” parts of the Internet can feel a lot happier – you wouldn’t necessarily realise there even was war.

The thing is that everyone, big and small blockers alike, agree that Bitcoin needs to scale.

The Bitcoin Core team have identified a few interesting ideas that they believe are the best way to scale Bitcoin, primarily Segregated Witness (SegWit), and Lightning Network.

Lightning Network is not popular with big blockers. It aims to move transactions off chain, sending them directly between individuals rather than being stored by every participant on the network.

They are skeptical, arguing that it is hypothetical and unproven, and that even if it achieved everything claimed, it does nothing to address the scaling problems that Bitcoin is facing right now. Many also believe that these transactions taking place “off chain”, are undesirable and not part of Satoshi’s vision.

They contend that on chain scaling is an essential and easy fix that can be implemented immediately, and that Lightning Network is a distraction, causing Core developers to neglect more pressing issues.

I can understand these concerns, but I also see the merit in the approach taken by the Core developers. In summary, an increase in blocksize is a barrier to running a node and reduces decentralisation, a sacred and essential property of Bitcoin which, they contend, must be preserved as much as possible.

Middle ground is hard to find when the argument is so subjective. On one side, a $0.09 transaction fee is far too high and going to put off new users so Bitcoin never grows. On the other a $0.09 transaction is far too cheap to require that every full node, thousands now, possibly millions in the future, is required to store details of $2 coffee purchases for thousands of years to come – leading to a bloated chain that will suffocate under its own weight and jeopardise the highly prized property of decentralisation.

SegWit seems to be a middle ground. It works by splitting the data from transactions into two parts, half of which can be included in 1MB blocks, the other half stored separately and not contributing towards the block size limit, while improving a other areas of Bitcoin (like transaction malleability) as an added bonus.

This, the developers claim, will give an effective block size increase to around 1.7MB without requiring that everyone upgrade their software (a hard fork).

Great news, you would think, the big blockers and small blockers can both agree this is a win win for Bitcoin. Also, there’s no longer need to wait, SegWit is coded, tested and ready for implementation.

The thing is, to the surprise of those who don’t frequent the big blocker communities, the frustration and suspicion has grown so pernicious that SegWit is not trusted. They don’t believe it does enough to address Bitcoin’s urgent scaling problem, has taken too long, and will take too long to come into effect.

There is almost a sense that, in accepting SegWit, they will have “lost”, and that they still haven’t been listened to. Some even argue that introducing SegWit as a soft fork is more dangerous.

All this frustration and bad feeling has manifested itself in the rejection by the big blocker community of SegWit. They would rather block its implementation than “lose”.

You might think they’d be barmy to block something that is ready to increase Bitcoin’s capacity, but that is exactly the plan. They have lost complete confidence in Bitcoin Core and many would like to see a switch to a rival implementation, Bitcoin Unlimited, that would allow miners to decide the maximum block size instead.

There is a genuine belief that in blocking SegWit, they can force a stalemate that will enable them to push the community into choosing “their” scaling solution, and that they can still win the war.

If you’ve not passed by this community, this may sound absolutely outrageous. To everyone else, the war is almost over, but to those on the other side, battle has just commenced.

So, what happens now?

In order to be activated, SegWit requires 95% of miners to vote for its activation. Currently, mining pool ViaBTC has stated it will vote against SegWit, and since it has over 5% of hash power, it will succeed.

This leads to an interesting dynamic. To those outside the big block community, those that have most vocally demanded the network capacity increase are now the ones standing in its way. In a war of ideas, it’s hard to see that the big blockers are going to suddenly gain much new support when it looks like this.

How will the Core developers react? Well, I think they’ll patiently respect the 95% activation threshold.

It’s also interesting to note that a number of prominent Core developers signed an agreement in February about how to scale Bitcoin.

The agreement was that SegWit would be worked on as a priority, and the once finished the developers would take around 3 months to write code for a hard fork to increase the block size somewhere between 2-4MB.

They then went on to estimate that SegWit would be coded by April, and if that were the case the hard fork would be coded by July 2016. This is unfortunate, because this optimistic timescale has led to accusations that the Core developers had failed on their “promise” to code a hard fork by July.

Software often takes longer than hoped, but it is a shame this mention of July 2016 has led to some in the big block community feel like they have been betrayed and misled, when it was an estimate rather than a commitment.

If Core developers present had said SegWit would take until October 2016 instead of April 2016, it is possible that consensus may not have been agreed- and you could argue was agreed on false pretences. While I believe this was a genuine underestimation, I can understand why others already cynical would assume the worst.

So, what happens now? Well, SegWit will probably not activate, and the Core developers who signed that agreement will spend the next 3 months writing the code they promised for a hard fork – those present signed the agreement and their reputation now depends on it.

It would actually be good for the big blocker cause if the Core developers present reneged on the agreement, as they would be vindicated and would gain new support.

In the meantime, the big blockers will promote Bitcoin Unlimited, and despite their overwhelming optimism in the face of what to many looks like adversity, it will probably face the same fate as Bitcoin XT and Bitcoin Classic, similar attempts which failed before it.

Around 3 months from now we’ll possibly still be waiting for SegWit activation, but we’ll probably have code for a blocksize increase. The thing is, part of the agreement was that the code would not be implemented by Core until after SegWit had activated.

At that point, I feel the guns may fall silent, and the great Bitcoin war could finally reach its conclusion.

John Hardy
Follow me

John Hardy

Software developer living in UK.
Longtime Bitcoin advocate.
Email [email protected]
Donations welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE
John Hardy
Follow me

Author: John Hardy

Software developer living in UK. Longtime Bitcoin advocate. Email [email protected] Donations welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE