I know we’re all tired of the block size debate, but it’s still front-and-center because of the looming 2X part of Segwit2X.

While debating this issue I have learned a lot. (I’m still learning, catching up with aspects of the debate that were months or even years old.) Reading up on both sides, I found the above quote from Peter Rizun. Here it is in further context:

“After visiting with Coinbase on 16 March 2017 and with Bitpay on 20 March 2017, this is the message that resonates inside me: ‘the upgrade to larger blocks must be decisive and absolute.’ The community does not want the blockchain to split. A split would threaten Bitcoin’s network effect, cause confusion in the media, and create unnecessary work for many Bitcoin businesses.” [emphasis added]

I disagree with Rizun on some issues, but I have to respect his excellent work on some other topics. In particular, I agree with the above quote in that it identifies what both sides really want: a single Bitcoin network that works for everyone. Unfortunately, we still are fighting over what that Bitcoin should look like.

I used to support Segwit2X, or at least the concept of a 2X increase along with Segwit. I still don’t believe it would be that dangerous to decentralization. We can handle it today with current hardware and not lose large numbers of nodes. I even tried to persuade some Core devs on Reddit to go along with it for the sake of keeping harmony and showing good will to those who had helped us activate Segwit, even though Core wasn’t part of the NYA.

However, after evaluating the other issues surrounding the specific Segwit2X project, I had to change my mind. It is clear the goal of some is to replace or “fire” Core completely, something I was never on board with, and would clearly be disruptive. It has also become clear to me that the community is very split and is not ready to accept 2X. In Rizun’s words, the hard fork will not be “decisive and absolute” by any measure; on the contrary, it is very contentious.

2X: good in concept, but not a long-term solution

In the big view, we’re talking about a relatively small 2X increase. This 2X bump would be nice in the short-term, but is not a major game changer. It is peanuts compared to the orders-of-magnitude scaling we need for Bitcoin to achieve world dominance. The smart and perhaps only way to achieve this and still keep Bitcoin decentralized is to build second-layer scaling solutions which multiply the reach of the base layer of Bitcoin far beyond what linear on-chain scaling can do. Long-term, I’m bullish on Bitcoin’s prospects with the Lightning Network and other similar technologies.

What we all really want… but it requires 2nd layer solutions

In contrast, right now, the risks/costs of Segwit2X far outweigh the benefit of a modest 2X increase. A split would cause us to lose many of Bitcoin’s best developers, experience chaos and potential financial loss, “threaten Bitcoin’s network effect, cause confusion in the media, and create unnecessary work for many Bitcoin businesses” (thanks, Rizun, for putting it so clearly).

Not what anyone agreed to!

So is there consensus? Can we upgrade in a “decisive and absolute” way?

Miners may be “signaling” 94% support for Segwit2X right now, but they are only 1 of at least 4 major groups with a stake in Bitcoin. The other three are: businesses, devs, and users (for whom Bitcoin exists, in the end). According to https://coin.dance/poli, only 21% of businesses support Segwit2X (62% are neutral, 17% actively oppose it). We know that Core devs at least are nearly unanimous against Segwit2X (https://en.bitcoin.it/wiki/Segwit_support). Unfortunately, we don’t have a good way to gauge users’ opinions with accuracy, but we can at least say that they are divided with no clear majority.

Given that only 1 of the 4 major groups in the community has “consensus” and the rest are divided or opposed, it’s obvious that agreement on Segwit2X is anything but “decisive and absolute.”

For the sake of keeping one chain, a goal we all agree on in principle, isn’t it time for companies like Coinbase and Bitpay to shelve this hard fork for now? I know there are egos and agreements on the line, but in the end, breaking Bitcoin will be worse than living with a Segwit-enhanced block size limit (which is now up to ~2MB, already ramping up toward a doubling in actual block size) for another year or two until other solutions come into play. NYA participants should begin to meet together, remembering the larger/original goal, and give each other permission to re-evaluate their agreement in light of the current situation.

And to make this easier for them to do, shouldn’t Core also ease their concerns by at least starting to plan now for a smarter, better-tested hard fork in a year or two? Seeing a solution on the roadmap, perhaps anxious businesses wouldn’t put as much pressure on the community to implement short-term, stopgap hard forks that cause greater problems than they solve.

For example, Greg Maxwell mentioned “flex caps” as being “further out” on the roadmap published almost two years ago. Most of the more concrete items on the roadmap have been completed. Perhaps it would ease the tension in the community, and allow businesses to plan their own expansion better, if Core put something like the flex caps proposal on an updated roadmap for the next 2 years. This is after all a much smarter solution than just raising an artificial ceiling; and it still encourages a good fee market to develop.

I used to think 3+ months would be enough for a simple 2X hard fork, but it has clearly not been enough time. Instead, when we hard fork we should do it as Satoshi advised:

It can be phased in, like:if (blocknumber > 115000)

maxblocksize = largerlimit if (blocknumber > 115000)

maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete. [emphasis added] When we’re near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

(https://bitcointalk.org/index.php?topic=1347.msg15366)

Notice the second part that the big-blockers often leave out when quoting Satoshi on this: he clearly advised Jeff Garzik in this thread that it needs to be baked into the code way in advance, to avoid a disruptive hard fork.

In other words, we can raise the block limit, but it should be done cautiously and at least a year in advance, so that the majority of clients are upgraded and it goes off without a hitch. Following a similar cautious approach, Segwit code was present in 0.13.1 and thus deployed for a long time before it finally activated. Granted, it was a soft fork… but all the more reason for a hard fork to be AT LEAST a year in the making.

To close, I return to Peter Rizun:

…how I suspect the upgrade to larger blocks will unfold (hint: it will be anticlimactic).

The reality today appears to be completely the opposite.

Segwit2X supporters and companies: Please reconsider pushing ahead so recklessly! The costs far outweigh the benefits.

(P.S. This is my first post on Medium. I am on Reddit as u/scientastics)

Image credits:

http://4.bp.blogspot.com/-7nZT6OgCGx0/VIIQri9a_SI/AAAAAAAAFAc/xjtf92XWrw8/s1600/559160204.jpg

http://1111.solutions/wp-content/uploads/2016/05/Fish-Jump.jpg

http://www.freakingnews.com/pictures/33500/Fish-Bowl-Cut-in-Half-33719.jpg

Updated/edited on Oct 6, 2017.