[Solved] I propose a new fork terminology to clarify upgrade discussions

Consensus
#1

In my discussion with @Calin yesterday, an interesting issue came up.

It would appear that current terminology of what is a “hard fork” and what is a “soft fork” is very unclear when it comes to actual meaning. This leads to upgrade option discussions being made more difficult than they should be and general misunderstandings about the discussion topic.

Current, public semi-official definitions are here, but in yesterday’s discussion we have pretty much concluded the definition of soft-fork is actually either wrong or unclear:

Instead of trying to update these definitions, which may be hard or even close to impossible because of public perception is already written in stone pretty much, I propose new terminology for Bitcoin Cash and PoW-based blockchains:.

Cherry Fork = A blockchain fork, that introduces changes that are non-backward compatible, which requires all nodes and clients to upgrade in order to keep using the network. Clients/Nodes that have not upgraded, are dropped off the upgraded network.

I chose Cherry because it is red, which is inspired by the universal color of STOP sign, this says “stop, you should upgrade here”.

Orange Fork = A fork, where new functionality is added that can be used by new clients only, but old, not-upgraded-clients can keep using the network the way they used it before, while being oblivious to new added rules/functionalities.

I chose orange as the fruit, because it’s color matches BTC logo of which developers favour this way of doing upgrades. Also orange colour is the universally accepted colour that says “slow down, you need to think about this” everywhere around the world.

3 Likes
#2

Also calling @cculianu

#3

The investopedia link doesn’t make any logical sense, but I find the canonical definitions to be pretty concise and useful.

A “hard fork” is a fork that relaxes or the consensus rules or removes some of them, or changes them in an incompatible manner. It is hard because it requires an update by the bystander nodes.

A “soft fork” is a fork than restricts or adds consensus rules. It’s soft because non-upgraded bystander nodes will still be able to keep up with the updated chain.

It’s all moot to me, as “soft fork” forks are generally unnecessary.

1 Like
#4

I wonder if the source of confusion isn’t more about the difference between hard forks and network splits, which admittedly overlap a bit.

1 Like
#5

WOW, I have no idea whether you realize this, but the explanations of soft-fork and hard-fork terms you just supplied are extremely hard to understand to a layman. “Consensus”? “Changes in an incompatible manner”? “bystander nodes”?

Your mother surely won’t understand that. But she may understand if you explain that you need to upgrade and she has too old an app to use new, upgraded Bitcoins.

She may even understand that she does not necessarily have to upgrade, because the change (orange fork) adds some new stuff, but also allows her old app to still work with just using the old stuff.

I attempted to create easily-recognizable terminology that will not only be strict, but also layman-compatible.

Perhaps my attempt was also a PR move but I did not realize that at the time I was writing it. My bad I guess.

I am generally not very good at articulating why I think that are my ideas are good ideas, as I have no social skills that enable me to live within a group - so I assume this proposal will not make it anyway, but it was still a nice try.

#6

There are not only “soft forks” and “hard forks” but also non-consensus changes. And then there are SPV clients that don’t care about some hard fork, but may break because of a non-consensus change.

For a full node, a hard fork means that old software gets stuck and doesn’t see any new transactions, or it may even see some transactions that some unimportant miner mined on the old chain that are not real.

A soft fork means that the full node may sometimes see some blocks that are later replaced by other blocks, so it is basically degraded and low confirmation is as insecure as zero confirmation (which is insecure when a soft fork exists that the software doesn’t know about). The full node may even follow the “wrong” fork, but in that case the question is, if you want to follow the fork the developers chose (the “right” fork) or the fork the miners chose (the “wrong” fork).

A non-consensus change means that a full node has the correct picture for all confirmed transaction, but may have the wrong picture for unconfirmed transactions. An example is the mempool chain limit. I mostly affects security of 0-conf transactions.

And then the question whether you need to upgrade can be very different from whether it is a soft fork, a hard fork, or a fork at all. For example, Schnorr signatures was a hard fork, but most SPV clients were not affected at all. They can still send transactions using the old format and they don’t check incoming signatures. On the other hand changing from the legacy 1… bitcoin address to cashaddr was neither a soft fork, nor a hard fork, but basically just a UI change. Nonetheless if you didn’t upgrade, you can barely do any transaction nowadays.

3 Likes
#7

This is insightful, thank you.

Apparently no new terminology is needed, because it would be too unclear anyway as there are multiple more possible options of upgrade and introducing another “colors” would complicate things too much.

Case closed.

2 Likes
#8

“which requires all nodes and clients to upgrade in order to keep using the network.” Any language that suggests there is a requirement to upgrade a node to keep using the network is authoritarian in nature and not useful to describe the realities of a decentralized network.

1 Like