[Completely end the debate between soft and hard forks] A safe hard fork is a soft fork expansion

The expansion dispute has now become a tangled mess, with the opinions and interests of various parties entangled, making it difficult to see the essence of the event. The purpose of this article is to completely remove the soft and hard fork dispute, which is irrelevant to the expansion, from the expansion dispute and restore the original appearance of the expansion dispute.

Simply put, capacity expansion is the goal, and hard and soft forks are the means. Capacity expansion does not necessarily have to be achieved through a hard fork, it can be achieved through a soft fork. Opposing a hard fork does not mean opposing capacity expansion .
Don't believe it? Can soft forks also expand capacity? Have we been taught by Core for too long that "capacity expansion = hard fork = coin split = danger"? Let's take a look at the nature of soft and hard forks.

Simply put, whether old nodes accept new blocks is the essential difference between soft forks and hard forks . In soft forks, the scope of rules is narrowed, so old nodes will naturally accept new blocks.

But this definition is incomplete. It does not discuss changes outside the rules. For example, in the Segregated Witness (SW) fork, the Core development team removed the signature data of the transaction from the original block data structure and placed it in a new data structure that the old nodes could not read. Simply put, some data that the old nodes could not read was placed outside the rules. Is this fork still a soft fork? According to the current industry attitude and Core definition, this is also a soft fork - because the old nodes were deceived into accepting the new block.

Then let’s look at the hard fork. After the DAO theft, ETH’s hard fork failed and two coins were split. As a result, many people became afraid of hard forks and even began to praise Core’s “brilliant foresight”, which was really a bit laughable.

The failure of the eth hard fork was largely due to errors in the execution of the fork - no consideration of the handling of small forks . eth decided to fork amid controversy, first deciding on a soft fork, then hastily switching to a hard fork in the last few days due to the complexity of the soft fork (which was eventually found to have bugs). The eth community is not as mature as the BTC community, so it did not consider the handling of small forks at all.

At the beginning, the ETH hard fork seemed to be going smoothly, and the original chain had almost no computing power left. However, Poloniex exchange unexpectedly launched the original chain (etc coin), and a large amount of original chain supporters and speculative funds poured in, raising the price of etc, and then attracted miners to come back to mine etc with higher returns, which eventually led to the small fork original chain having enough computing power to survive, and the ETH hard fork failed.

So what should be the correct hard fork posture?

"Based on implementation" is simple. As early as July 4, I published an article "Calling on Ant Pool to Commit to Invalidating Forks Below 25% and Maintaining the Unity of Bitcoin", suggesting launching a 51% attack on small forks (not packaging any transactions, and isolating and invalidating any blocks containing transactions) to ensure that no transactions can be performed on the small fork, thereby killing the small fork .

The advantage of "implementation-based" is that no code changes are required, but the disadvantage is that there may be variables in human implementation. "Implementation-based" was feasible before the ETH hard fork, but after the failure of the ETH hard fork, it can be predicted that if BTC hard forks, a large number of speculators will inevitably support the original chain in terms of computing power and price, adding greater variables to human implementation. Therefore, from the current situation, "code-based" appears to be more secure.

A safe hard fork can ensure that after 75% of the hashrate is forked, the small fork will be completely killed. Of course, some people will protest at this time: "Why do you kill the small fork? Since there are people supporting it, why don't you give the small fork a way out and let it develop on its own?" "You are the majority coercing the minority, which is evil! It is unjust!"

Well, the label of "the majority coercing the minority" is too broad, and it will take another article to discuss it. Let's just talk about the actual situation: the reason why soft forks are "safe" is that the majority coerces the minority .

Everyone knows that soft forks have an activation threshold. For example, if 90% of the computing power is activated, what will happen to the remaining 10% of the computing power after activation? For example, if the soft fork shrinks from 1M to 0.5M, the 0.5M block mined by 90% of the computing power will be accepted by 10% of the computing power, and 10% of the computing power will continue to mine on the block chain mined by 90% of the computing power. But on the other hand, the 1M block mined by 10% of the computing power will be considered an invalid block by 90% of the computing power (the rule range is reduced to 0.5M), and any block mined by 10% of the computing power will be isolated and invalidated. This is an attack launched by 90% of the computing power on 10% of the computing power in both technology and nature .

So, accusing the majority of coercing the minority? Then Bitcoin should not undergo any upgrades. Further logically, any rule change (whether it is to expand or reduce the scope of the rule) cannot have 100% consensus. Should we choose a hard fork that splits into two chains? Or a soft fork that coerces the minority? :)

What’s even more interesting is that the reason why secure hard forks and soft forks are exactly the same in terms of enlisting the minority is that secure hard forks are, by definition, exactly the same as soft forks. Secure hard forks are soft forks.

To be precise, a safe hard fork is an intersection of a hard fork and a soft fork. It has the advantages of a soft fork that does not split, and the advantages of a hard fork that does not leave technical debt and is a thorough upgrade.
As we all know, forward compatibility comes at a price, and IE6, which is hated by all web developers, is a typical example. There are huge technical risks in soft forks that are forward compatible, even if they rely on deceiving old nodes to achieve forward compatibility like Core's Segregated Witness (SW) soft fork.

To use a not very accurate analogy for non-technical people, Core has to deceive old nodes and make it look like nothing has changed even though the underlying data structure has changed. The difficulty is equivalent to creating the twisted hand in the picture. The technical risks and the technical debt that will be incurred in the future are self-evident. It is conceivable how difficult it will be to do further development on this twisted hand.

Why do Core developers say that "the Segregated Witness soft fork modifies almost every line of Bitcoin code"?
Why is it that the Segregated Witness soft fork, which should have been released in April 2016 and launched in July according to the Hong Kong Roundtable, has not yet appeared in October under the huge pressure from the consensus protocol and miner pools?
Because what Core was trying to create was a twisted hand like the one in the picture.

A safe hard fork does not have such technical risks at all. It will not lead to a split into two chains, and it will urge all old nodes to upgrade (no transactions can be performed without upgrading), without having to bear the technical debt of forward compatibility .

Therefore, let's keep the expansion as expansion and the hard and soft forks as hard and soft forks. If you agree to expand but are worried about splitting, you can use a soft fork (safe hard fork) to complete the expansion. If you disagree with the expansion, you can also focus on discussing the pros and cons of the expansion instead of "I oppose hard forks, so I oppose expansion."