2x or NO2X: Why Some Want to Hard Fork Bitcoin — and Why Others Do Not

NO to more security tradeoffs

SegWit2x opponents generally agree that increasing Bitcoin’s block size comes with a number of tradeoffs.

For one, bigger blocks increase resource requirements for operating a full node, such as more bandwidth use, longer sync time for new nodes and more. This increases the cost for individual users to partake in the network in a trustless and therefore optimally secure manner. This increased cost could, in turn, have a centralizing effect on the network, especially if it results in fewer users running full nodes.

Additionally, bigger blocks would slow down block propagation over the peer-to-peer network, which potentially benefits larger miners and mining pools: another centralizing effect.

And it may actually be good to limit network throughput to some extent, as this increases fee pressure, which in turn provides an incentive for miners to secure the network as block rewards dwindle over time.

All these types of risks can ultimately lead to a more centralized and therefore less censorship-resistant and less permissionless Bitcoin. This is sometimes referred to as the “PayPal 2.0 risk,” where Bitcoin degrades to lose what SegWit2x opponents consider to be its defining features and main value propositions.

With the activation of Segregated Witness, Bitcoin allows for a worst case of four-megabyte blocks, increased from one megabyte. Some consider this to be a somewhat risky compromise already. SegWit2x would double this risk to a worst-case total of eight megabytes, which SegWit2x opponents generally consider too big for now.

NO to “backroom deals”

While the details are a bit unclear (and that is part of the problem), SegWit2x was forged between a relatively small group of (mostly) executives from prominent Bitcoin companies during an invite-only meeting in a hotel in New York, organized by the Digital Currency Group.

After agreeing on what they considered to be a compromise between the two sides of the scaling debate, they reached out to other companies to sign on to the agreement. The aggregate customer base of all these signatories is claimed to be represented by the agreement, as is all hash power connected to participating mining pools.

Further, while BTC1 technically has an open development mailing list and a open Slack discussion channel (though both were initially closed), not much discussion is taking place in either of these venues. This either means that not much development discussion is taking place at all — or that these discussions are taking place within an unknown closed environment, too.

All this is in stark contrast with the open-source ethos in which Bitcoin was born and which still permeates Bitcoin’s development process today. Bitcoin Core contributors, for example, meet and discuss publicly on IRC, while potential protocol changes (BIPs) are discussed on a public mailing list; both communication channels are relatively active.

Moreover, SegWit2x opponents typically consider it a key feature of Bitcoin that users are in control of their own money. While companies may provide services, SegWit2x opponents don’t think these companies should get to decide what defines Bitcoin on behalf of their customers and should definitely not make them on behalf of all Bitcoin users.

All this is not just a matter of principle: opponents believe SegWit2x could actually set a bad precedent. If a small group of companies is shown to be effectively in control of the Bitcoin protocol, these companies could become a sort of central point of failure. Governments could, for example, exert pressure on them to introduce black lists or other infringements on (what they consider to be) Bitcoin’s core features.

NO to “firing” Bitcoin Core

While Bitcoin Core is indeed the dominant client on the Bitcoin network, this is only because users voluntarily choose to run this software — and many SegWit2x opponents, at least, are happy to do so. They have no desire to “fire” the Bitcoin Core development team at all.

It’s also not clear if any group of developers can or will take the place of Bitcoin Core’s current contributors should they be “fired.” Not many people in the world have as deep an understanding of Bitcoin’s codebase or inner workings as they do.

BTC1, for example, really has only one developer doing most of the work on it: Bloq CEO Jeff Garzik. Garzik does have experience working on the Bitcoin Core codebase, but his core experience is not in working on consensus-critical code. This also means that testing and review of BTC1 is rather minimal.

And while some SegWit2x proponents hope and believe that Bitcoin Core developers will merge the SegWit2x code or otherwise shift their efforts to the SegWit2x version of Bitcoin after the hard fork, this seems very unlikely: the project went so far as to issue a rare joint statement rejecting SegWit2x. Instead, if the SegWit2x hard fork were to succeed and the current Bitcoin protocol were to stop functioning, several Bitcoin Core developers have indicated they’d consider that outcome to represent a failure of Bitcoin itself and would choose to move on to different projects altogether.

Lastly, it should be noted that — while dominant — Bitcoin Core is not the only software client that embeds the current Bitcoin protocol. Bitcoin Knots, Libbitcoin, Bcoin and a range of other alternative implementations do so as well. SegWit2x would arguably be “firing” not just Bitcoin Core but most of the entire development community.

NO to contentious hard forks

Since not everyone agrees that the SegWit2x hard fork is the best way forward, or even beneficial at all, it is contentious. And many SegWit2x critics oppose any contentious hard fork for two main reasons.

The first reason is philosophical. SegWit2x opponents think that Bitcoin’s gold-like resistance to change is one of its key value propositions. More specifically, they maintain that the rules of the system should not be changed against a user’s will: that would undermine trust in this type of money.

The second reason is similar, but more technical: not only shouldn’t the rules be changed against a user’s will, the rules cannot be changed against a user’s will. As long as users run full nodes and do not switch to SegWit2x, the original Bitcoin protocol will continue to exist. As such, a hard fork like SegWit2x won’t actually change the existing Bitcoin at all; rather, it would create a new blockchain and a new currency — a coin-split.

This also explains why SegWit2x is not considered a “compromise” by opponents. For them, the SegWit2x hard fork is not a middle-in-the-middle compromise. Instead, such a contentious hard fork is precisely the thing they do not want.

NO to rushed hard forks

Even if the hard fork was not contentious, SegWit2x opponents would consider it rushed. Since everyone needs to upgrade for a hard fork to be successful — that is, there is no resulting coin-split — many think that typical hard forks should require a year of lead time at the very least, and maybe even two years or longer.

SegWit2x had a lead time of three months since SegWit activation and about six months since the agreement was made. Opponents consider this recklessly short even for popular hard forks — never mind contentious ones.

NO to a lack of replay protection

If SegWit2x does lead to a coin-split — and the current lack of consensus suggests that it will — there would be two blockchains and coins with a shared history: one coin that follows the current Bitcoin protocol and one coin that follows the SegWit2x protocol. Anyone who owns bitcoins at the time of the fork will then own both of these coins.

But this could also mean that most transactions will be equally valid on both blockchains. Whenever anyone wants to send coins on one chain, this exact same transaction could be “replayed” on the other chain, meaning both types of coins are actually spent on both chains, even if it was unintentional. This is known as a “replay attack” and can easily lead to a loss of funds.

These replay attacks can be prevented if BTC1 implements “replay protection.” But as it currently stands, the BTC1 team has no intention of implementing such protection; at least, not in such a way that would properly solve the problem.

This lack of relay protection is considered disruptive and even reckless, not only by the opponents of the hard fork but also by several signatories of the NYA: some have already dropped out for this specific reason.

For more on replay protection, see this article.

NO to brand confusion

Aside from replay protection, another big problem in the case of a coin-split could be brand confusion between the two types of coins.

If users (and service providers) on both sides of the split consider their coin to be the “real” Bitcoin, it’s not hard to imagine how this could lead to all sorts of complications. Users could, for example, buy one type of coin from an exchange even though they meant to buy another. Or they could send one type of coin to a merchant while they should have sent another. And so forth.

Such confusion could easily lead to a loss of funds, and perhaps even lawsuits and similar problems. (Even with Bitcoin Cash — which did pick a somewhat new name and added replay protection but not a new address format — there are many cases of confused users sending bitcoins to Bitcoin Cash addresses and the other way round.)

Opponents of SegWit2x maintain that it’s the coin that results from this hard fork — the coin that follows a new protocol — that should pick a new name. But so far, NYA signatories have shown no willingness to do so.

NO to keeping a broken agreement

While the intent of the NYA was to keep the Bitcoin network together, SegWit2x opponents consider this agreement to have essentially been broken since.

Segregated Witness did activate on the Bitcoin network, probably in part thanks to SegWit2x, but also instigated by the BIP 148 UASF. However, some proponents of a block size limit increase hard fork (and opponents of SegWit) also launched Bitcoin Cash in response. This realized a “split” between the Bitcoin and Bitcoin Cash blockchain and currency, not unlike the split Bitcoin Unlimited could have effectuated. Several NYA signatories — including Bitmain and Bitcoin.com — now support this fork, which SegWit2x opponents contend would nullify the original SegWit2x goal.

On top of that, several other signatories have since formally withdrawn their support, either because of the aforementioned lack of replay protection or for other reasons.

SegWit2x opponents therefore argue that the agreement, for all intents and purposes, has been broken and that there is no reason for the remaining signatories to keep to it.

NO to miners being the deciding factor

And finally, SegWit2x opponents believe that its proponents misunderstand how Bitcoin consensus and incentives work.

Instead of setting the protocol rules, SegWit2x opponents maintain that miners need to follow the protocol rules, as enforced by users and their full-node clients. If miners mined blocks that are incompatible with the Bitcoin protocol as defined by users, these miners would not really be mining Bitcoin at all. Instead, the “blocks” they’d produce would simply be rejected by the network of users, and these miners would be mining a different coin at best or wasting their hash power at worst.

And again, this is not just a matter of principle. If miners were to decide which protocol is valid simply by dedicating hash power to it, it would imply that they can change any protocol rules. This would even let them change the inflation schedule to remove the 21 million coin limit, steal funds and more.

Indeed, it’s no coincidence that the NO2X protest movement has much overlap with the BIP 148 UASF initiative: both maintain that users are in charge. Users decide which coin they want to buy, accept for payment and/or hold. As such, users decide which protocol is (more) valuable to dedicate hash power to: the original Bitcoin protocol or the SegWit2x protocol. This is the protocol that miners will want to mine; not the other way round.