Bitcoin Core contributor and Ciphrex CEO Eric Lombrozo was recently interviewed on Epicenter Bitcoin, and he used a portion of his time to explain some misconceptions and misunderstandings related to the block size limit debate.
While the focus of this development controversy has mainly centered on the actual block size metric in the Bitcoin protocol, Lombrozo says this misses the main point of disagreement. In his view, a hard fork is what the Bitcoin Core development community would like to avoid over the short term.
The Hard Fork Is the Issue
When explaining the full picture of the block size debate, Lombrozo made the point that the non-technical Bitcoin community (likely a reference to Bitcoin subreddits) may not have had the full picture of what was going on in the development community back in May of 2015. Lombrozo described the debate that took place among developers during this period of time:
“I think that a lot of the non-technical community and the public were not really witnessing exactly the whole development as far as what the developers were doing. Way back in May, we were already talking about considering these ideas when it was first proposed to the mailing list, and people were actually really trying to pick this apart and figure out all the things that could possibly go wrong. It quickly became apparent that hard forks have very significant stability issues, they can potentially open up attack vectors, and it could be very dangerous for the network.”
Although progress has been made on the simplicity of soft fork deployments, hard forks are still hard. At the recent Blockchain Agenda Conference in San Diego, Lombrozo detailedBIP 9, which allows for several new features to be applied to Bitcoin via simultaneous soft forks.
Contentious Hard Forks Should Be Avoided
Getting deeper into the problems with hard forks, Lombrozo made it clear that such changes to Bitcoin’s consensus rules are not impossible. Instead, he said contentious hard forks are the ones that should be avoided. Lombrozo noted:
“I am very concerned about hard forks. That’s not to say it’s impossible to do a hard fork more safely, [but] I think the only way that’s viable is if there isn’t this kind of contentiousness – if you don’t have a lot of polarization and people kind of fighting over different things. If most of the network agrees on something – if something is pretty much uncontroversial – that’s fine.”
Bitcoin Classic is a new implementation of the Bitcoin protocol with an increased block size limit of 2 megabytes. This change in the block size limit would require a hard fork, and it is enabled 28 days after 750 of the last 1,000 blocks have been found by miners who support the increase.
Many Bitcoin Core contributors find this hard fork to be contentious and would like to see something in the 90 to 95 percent social consensus range. Although an intentional hard fork has never been attempted on the Bitcoin network (Note: One change implemented in 2010 and activated in 2012 had implications somewhat similar to a hard fork), 95 percent approval from miners has been the standard for past soft forks.
We All Want Bigger Blocks
Lombrozo said everyone would like to see the Bitcoin network scale via an increased block size limit. He explained:
“As far as the block size itself, I don’t think there was much issue with bigger blocks. I don’t think many of the Core developers actually said, ‘No, we should never have bigger blocks.’ I think, for the most part, the idea of having bigger blocks is something that is appealing. We should find a way to have bigger blocks; we all want bigger blocks. But just increasing the blocks by changing a constant in the code presents a lot of very, very serious problems.”
In other words, Bitcoin Core contributors would like to see a solution to the block size limit issue that does not involve a contentious hard fork.
Segregated Witness Is the Best of Both Worlds
Until recently, the concept of increasing the block size limit while also avoiding a hard fork was theoretical. Bitcoin Core Developer Pieter Wuille presented Segregated Witness (SegWit) at the Scaling Bitcoin Hong Kong Workshop to near-universal acclaim. Lombrozo described how this solution provides developers with the best path forward:
“It turns out, if we want to do this and do it safely, we probably have to retrofit some stuff and do a lot more risk mitigation, which is what we’re trying to do with this. With SegWit, we kind of get the best of both worlds. I mean yes, it’s not a single, constant change in the code – it does require a bit of modification to applications – but it’s not a very significant modification. And it’s much safer from all of the other aspects of it. It really does not cause all of the stability issues that just changing this constant does.”
Some detractors of the SegWit soft fork have noted the changes to Bitcoin wallets required by this proposal are too cumbersome, but Lombrozo said that the wallet developers he’s worked with have been able to implement the required changes in a few days. The Bitcoin Core website also lists the wallet providers who plan to support SegWit.
The Soft Fork Is Almost Like a No-Brainer
In Lombrozo’s view (and Bitcoin Core’s view according to their roadmap), the Segregated Witness soft fork is nearly a no-brainer. The Ciphrex CEO explained:
“Block size was never really the issue; that was never really what people were arguing about. It was much more about this hard fork thing – whether we should do a hard fork or not. Now that we have a soft fork way to do it, it’s almost like a no-brainer.”
Lombrozo went on to say that there is general consensus among the Bitcoin Core development community that the network cannot handle blocks much bigger than 2 megabytes right now. This means a hard fork to anything over 2 megabytes would likely not gain social consensus among Bitcoin Core contributors. Segregated Witness also comes with a variety of benefits unrelated to the block size limit, which Lombrozo has discussed in the past.
Kyle Torpey is a freelance journalist who has been following Bitcoin since 2011. His work has been featured on VICE Motherboard, Business Insider, RT’s Keiser Report and many other media outlets. You can follow @kyletorpey on Twitter.