Bitcoin Core developer Eric Lombrozo recently wrote a blog post explaining why he supports BIP 148, which will force the activation of Segwit via a user-activated soft-fork. The activation of Segregated Witness, or Segwit, will lead to the expansion of the Bitcoin platform via layer…
Bitcoin Core developer Eric Lombrozo recently wrote a blog post explaining why he supports BIP 148, which will force the activation of Segwit via a user-activated soft-fork.
The activation of Segregated Witness, or Segwit, will lead to the expansion of the Bitcoin platform via layer 2 solutions such as Lightning Network. Others can, of course, come along. But no serious scaling plan at present truly suggests abandoning miners. Miners would simply have to start mining Segwit-friendly blocks when the time came, or risk losing money, because an alternative chain would ultimately be considered invalid in August.
A little over two years ago, the scaling issue was brought to the bitcoin-dev mailing list. Specifically, a 20MB hard fork proposal that had been sold behind closed doors to industry had been leaked to the mailing list. This was the first time since I had started working on Bitcoin that I feared the single property I most cherished about Bitcoin was at risk — that the rules underlying how the ledger converges might be altered arbitrarily just because a few people got together in a room and agreed on something in private. […] Since then, I worked diligently to try to listen to industry concerns and meet with stakeholders. I tried to listen to all points of view and to seek a solution that would best satisfy all interests with as little disruption to the network and without sacrificing that most cherished property mentioned earlier.
The overall conclusion should be simple for anyone observing: Segwit should be activated, sure. Forcing it is interesting, but perhaps not the wrong approach. Moving forward, though, suppose that even with Lightning Network, for some reason, we were going to need larger blocks. One hopes at that point larger blocks would be accepted.
Otherwise you’d just have large, large amounts of Lightning transactions, all having paid reasonable fees and their stewards having, in turn, paid fees, waiting to be processed. This would be an interesting and hard situation for the network, and if an actual block increase were required then, one wonders whether it would be such an issue of contention.
I believe it is everyone’s fundamental right to run whatever code they want on their computers, whether it be Bitcoin Core or Bcoin or BTCD or some custom branch of these or something entirely different. If the economic incentives of the network can’t keep us all in consensus without requiring coercive means, something seems to be fundamentally broken about Bitcoin.
There’s actually no incentive for the miners on the other side of the argument to go against the user fork away from non-Segwit blocks. Segwit and larger blocks don’t actually conflict as scaling solutions. They can work in concert, and once we see the limits of Lightning and Segwit, we’ll hopefully be better able to gauge what it’s going to take to handle the entire load of the network. Hopefully there will be easy to use web interfaces for generating transactions on the Lightning network, as well as other networks that are launched with the advent of Segwit to perform the same purposes.
It will be better to see more developers take more neutralized or rational stances on what they are proposing or demanding from Bitcoin. It’s clear there are some on all sides with actual, financial motivations for what they do, but we all share in the gains when the price of Bitcoin continues to rise. So we should continue to press for things that will help that along. Segwit, Lightning, and a blocksize increase would all add up to these.
Featured image from Shutterstock.
Last modified: January 25, 2020 12:10 AM UTC