For those who have not kept up with the debate, here’s an overview of the main arguments for and against the 2x hard fork part of SegWit2x.
A group of Bitcoin companies plans to deploy a hard fork to double Bitcoin’s block weight limit to eight megabytes this November. Known as “SegWit2x,” this incompatible protocol change follows from the New York Agreement (NYA) and is embedded in the BTC1 software client.
SegWit2x is highly controversial. Most of Bitcoin’s development community, a number of other companies, some mining pools and — if public polls and futures markets are representative — a majority of users and the market are not on board with this hard fork. Some of them are even engaged in a sort of protest movement, under the banner “NO2X.”
The advocates of a block size limit increase believe that one of Bitcoin’s main value propositions is its potential as a payment channel. They prefer on-chain transactions to be cheaper and faster than they have been recently, and think this is what the silent majority of users wants as well. SegWit2x proponents are often also a bit more willing to risk Bitcoin’s other defining features, such as censorship resistance.
With bigger Bitcoin blocks, the network can handle more transactions. This should drive average fees down and have transactions confirm faster. Or it should at least make it more expensive for attackers to spam the network with bogus transactions, if they do try to drive fees and confirmation times up. SegWit2x proponents therefore think that a hard fork to double Bitcoin’s block weight limit will onboard more users more quickly.
Faster adoption could, in turn, benefit Bitcoin in several ways. Bitcoin’s exchange rate could increase, which would also grow miner revenue, which should translate to more hash power to secure the network. Meanwhile, more total users may run full nodes to benefit geographic network decentralization. Furthermore, increased popularity might even make it harder for governments to ban Bitcoin.
The New York Agreement was born in the heat of Bitcoin’s scaling debate under the looming threat of a contentious hard fork led by the alternative protocol implementation Bitcoin Unlimited. This effort was, to a large extent, spearheaded by proponents of a block size limit increase and opponents of the Segregated Witness (SegWit) protocol upgrade, like Bitmain and Bitcoin.com.
These companies leveraged hash power from their mining pools to delay SegWit activation, while planning to increase the block size limit with a hard fork. This could have “split” the Bitcoin network into two incompatible blockchains and currencies.
SegWit2x was presented as a middle-of-the-road compromise between the two warring camps of the scaling debate. “One side” would get SegWit, while the “other side” would get a capacity increase hard fork. Most signatories believed, at least at the time of the agreement, that this would be a solution that should keep the Bitcoin network together.
YES to 2X keeping their word
While doubling Bitcoin’s block size would (probably) decrease average fees and/or confirmation times, the recent activation of SegWit did already decrease both quite a bit. What may, therefore, be more important for remaining signatories of the NYA is not so much the block weight increase but rather the agreement in and of itself. Dropping out of the agreement “halfway” — after SegWit activation but before the hard fork — would be a breach of the agreement they signed on to.
Not only that, but dropping out now could also be seen as an admission that SegWit was actually not so much activated because of the NYA in the first place — but rather because of the BIP 148 user-activated soft fork (UASF). Due to BIP 148’s controversial nature, not in the least among some of the NYA signatories, many may be eager to avoid the perception that this UASF was a success.
YES to “firing” Bitcoin Core
Currently, most people running full nodes choose to use a Bitcoin Core software client, making this the dominant implementation on the Bitcoin network. Some even consider it Bitcoin’s protocol-defining “reference client.”
SegWit2x appears to be at least partially motivated by the desire to remove the perceived power or influence that Bitcoin Core contributors have over Bitcoin’s protocol development, by having a majority of companies and miners switch to the BTC1 software client instead. (It should be noted that within this context, “firing” actually means “no longer using software maintained by these developers.” Bitcoin Core contributors are essentially volunteers and cannot literally be fired, while most of the code in the BTC1 client is forked from Bitcon Core and thus written by Bitcoin Core developers anyway.)
Bitcoin Core contributors could, of course, release a new Bitcoin Core client that adopts the SegWit2x hard fork to make it compatible with BTC1, and therefore compatible with these companies and miners. In fact, this might even be what many NYA signatories are hoping for. In that case BTC1 would effectively become Bitcoin’s new reference client, at least from the perspective of some of these signatories.
Other signatories may prefer the Bitcoin Core development team to quit altogether. In some cases, support for the hard fork may even be largely driven by resentment toward the Bitcoin Core project and a desire to take any action perceived to discredit it.
YES to miners being the deciding factor
Over 90 percent of miners (by hash power) are currently signaling support for SegWit2x. While this signaling itself is technically meaningless, SegWit2x proponents assume that miners will follow through on this stated intent.
Some SegWit2x proponents argue that miners decide the future of the Bitcoin protocol — or that miners should decide. If a hard fork were to result in two incompatible blockchains, they believe that whichever blockchain has more hash power dedicated to it is the “real” Bitcoin. Or, at least, they’ll maintain that the blockchain with the most hash power dedicated to it will be the more secure and functional “Bitcoin,” and thus the “Bitcoin” that people will want to use.
NO2X
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.
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.
Comments are off this post!