[Ending the Soft/Hard Fork Debate] — A Safe Hard Fork is the same as a Soft Fork

Original By: Jiang Zhuo’er
This post was translated from the Chinese version originally posted on 8btc.

The scaling debate has turned into a big ugly hairball in which the technical ideas, politics, and profit motives of all the players have become tightly entangled together, making it difficult for the casual observer to make heads or tails of the issues at the heart of this debate. The goal of this text is to perform a thoughtful and thorough analysis of both sides, to put an end to the fighting, and to cut to the main technological issues that are in contention.

Put simply, larger block size is the end, and soft- and hard-forks are the means to that end. Attaining a larger block size does not require a hard fork, and can be entirely accomplished by way of a soft fork instead. Opposing a hard fork ≠ opposing bigger blocks.

Don’t believe me? A soft fork can achieve bigger blocks? The rhetoric of Bitcoin Core has conflated “increasing block size” with “hard fork” with “a split in the currency” with “DANGER!” But let’s take a look at the fundamentals of soft and hard forks.

Basically, the primary difference between a soft and a hard fork is whether or not old nodes will accept blocks produced by nodes running the new software. Because soft forks tighten the rules, the blocks produced in this way naturally will be accepted by older nodes with more lax rules.

But this is not a perfect definition, we also need to look at changes in places other than just in consensus rules. For example, Core’s plan to roll-out Segregated Witness involves taking all transaction data past and present, removing the signature information, and placing it in a new data structure where old nodes will be unable to read it. So this change is not in the consensus rules, per se, but is putting data somewhere where it is not accessible to older nodes… is this a hard fork or a soft fork? According to current industry attitudes and the definition used by Bitcoin Core, this is a soft fork, because the older nodes have been tricked into accepting the new type of blocks.

Next let’s look at hard forks. After the DAO hack, the ETH hard fork failed (in the sense that it did not preserve 100% network consensus) and produced two different currencies. This failure caused many to change their attitudes towards hard forks and to fear them, with some going so far as to praise Core for their “brilliant foresight and vision.” Hearing this, I don’t know whether to laugh or cry.

The ETH hard fork was a failure in large part because it overlooked a critical aspect: how to deal with the minority chain. In the course of discussion on how to proceed, they first decided they would perform a soft fork, but later realized the complexity of a soft fork (and found a bug) and in the end hurriedly pushed through a hard fork. The Ethereum community is not quite as matured as the Bitcoin community, to the extent that they completely failed to consider the question of the minority chain.

At first it seemed as though the hard fork would be executed with precision; at the start of the fork the original chain had almost no hash power left behind to support it. But then the Poloniex exchange unexpectedly began to support trading of minority chain coins (ETC), and the money of speculators and original chain supporters came pouring in, giving the minority chain’s coins an exchange rate. Sensing an opportunity to make money, some miners began to mine on the minority chain again. In the end, the minority chain had enough hashrate to continue existing, and the ETH hard fork was a failure.

So what’s the right way to do a hard fork?

Handling the Minority Chain

• A hard fork must consider the question of how to address the minority chain. It can do this in one of two ways:
• With hashrate: intentionally 51% attack the minority chain to kill it.
• With code: a built-in attack mechanism to kill the minority chain. (Safe hard fork)

The “with hashrate” solution is simple. On July 4th of this year, I published an article titled “A Call for Antpool to Invalidate a <25% Fork, To Maintain Bitcoin’s Unity” [Chinese], in which I recommended 51% attacking a minority chain that had less than 25% of the hashrate of the original. This attack would not include any transactions, it would only invalidate any blocks containing transactions. This would ensure the success of the majority chain and preserve a unified currency.

The benefit of the “with hashrate” solution is that it does not require making any code changes. A downside of this method is that there are unknown variables. This method may have been more feasible prior to the ETH hard fork, but after its failure we can anticipate that should Bitcoin hard fork there will inevitably be some number of speculators supporting the minority chain with both capital and hashrate, increasing the unknown variables. Under present circumstances the “with code” method appears to be the more dependable of the two.

Safely Hard Forking with Code

• Two-Chains Method：The new chain and the old chain are merge-mined together. Miners can simultaneously mine coins on the new chain while perpetually attacking the old chain.
• Camouflage Method：Move all transaction data to a new location, much like how in a Segregated Witness soft fork roll-out the signature data is moved. Old nodes will not be able to read nor perform transactions.

After a safe hard fork attempt ensures it has 75% of the hashrate, it is possible to completely kill off a minority chain. Of course to suggest doing so is contentious. People will protest: “Why kill the minority chain? If people support it, why not let it survive and develop on its own?” “This is the tyranny of the majority over the minority, this is evil! This is not right!”

Addressing the question of the tyranny of the majority is a huge topic, and will require a separate essay to explore. But I am only speaking of the actual circumstances that exist right now: A soft fork is “safe” only because it requires the tyranny of the majority to succeed.

Everyone knows that a soft fork requires a certain activation threshold, for example 90% of the hashrate. After the threshold is reached, what about the other 10%? As an example, if a soft fork were implemented redefining the block size as 0.5MB, then the blocks mined by the 90% majority would be accepted by the 10% minority, and the 10% would continue to accept the blocks produced by the 90% as valid. On the other hand, the 1MB blocks produced by 10% of the hashrate would be deemed invalid by the 90%, and any block produced by the 10% would be orphaned. This is inherently and technologically the 90% launching an attack against the 10%.

As a result, how can we criticize the majority enacting changes and forcing the minority to comply? If that’s the case, Bitcoin should never be changed at all. To go a step further and follow this logic, any sort of consensus change in Bitcoin, whether tightening or expanding the rules, is impossible to perform with 100% consensus. Any time a consensus rule has been added to bitcoin, should two different blockchains have been created? Or should we accept the validity of the majority vote bringing the minority into compliance?

A safe hard fork and a soft fork are identical in that they both require the majority to force compliance upon the minority. By definition, a safe hard fork and a soft fork are one and the same. Thus my title: A safe hard fork is the same as a soft fork.

A Safe Hard Fork = Soft Fork

• A safe hard fork can force the original chain to have a 0MB block size, conforming with soft fork rules.
• A safe hard fork can restructure the transaction data in a way that incompatible nodes cannot read it, identical to the way that Bitcoin Core plans to implement the Segregated Witness soft fork.

A safe hard fork is precisely the intersection between a hard fork and a soft fork. It has the soft-fork benefit of not creating two new blockchains, and the hard fork benefits of not introducing technical debt while also enacting a complete upgrade of consensus software.

Everyone knows that maintaining backwards compatibility has a cost; every web developer’s hatred for IE6 is a textbook example of this. A soft fork’s backwards compatibility, just as in the case of Bitcoin Core’s Segregated Witness plan, depends on deceiving older nodes into accepting the new rules as valid. This brings with it tremendous technological risk.

For the non-technical readers of this piece, I will make a not-so-exact analogy. Core wants to restructure transaction data from the bottom up, as well as deceive nodes so as to maintain the appearance that nothing on the network has changed. The problem with this is much like the distorted hand in the image above. With the inherent technological danger and the introduction of tremendous technical debt that will be carried well into the future, it goes without saying that attempting to keep building upon this “distorted hand” will be a very risky proposition.

Why do the Core developers say that Segregated Witness should force a rewrite of almost every line of bitcoin code? According to the Hong Kong roundtable agreement, Segregated Witness would be released by April 2016, and the code for a hard-fork available in July. Under the signed consensus agreement and under considerable pressure from the miners and the pools, how is it now October and we have yet to see anything from Core?

Because what Core is attempting to build is just like the distorted hand.

A safe hard fork does not come close to having the same kind of technological risk. A safe hard fork will not lead to the creation of two new currencies. A safe hard fork also incentivizes nodes to upgrade their software as quickly as possible, as a node that has not upgraded will not be able to make transactions. A safe hard fork does not carry with it the technical debt that comes from maintaining backwards-compatibility.

Therefore, let’s get on with raising the block size. If you agree with a block size increase but fear a coin split, there is no reason not to support the use of a soft fork (safe hard fork) to accomplish this. If you disagree with increasing the block size, let’s discuss the pros and cons, but do not say “I oppose a hard fork, therefore I oppose a block size increase.”