YSK: The proposal to freeze Satoshi's coins and invalidate old transaction signatures is actually a SOFT FORK. Soft Forks can still cause reorgs and chain splits, and they can cause new clients to be incompatible with old clients.

TL;DR

90% of you don't know the actual difference between hard and soft forks. I wouldn't blame you since AI gets it wrong too when I ask.

The actual definition is surprisingly different than what most have heard. Hard forks are caused by loosening rules concerning which blocks are valid while soft fork are caused by restricting rules.

Soft forks can be just as "hard" and disruptive as hard forks but add additional complexity, technical debt, and bloat.

Despite popular opinion, soft forks can cause incompatibility because their backwards-compatibility is only 1-sided.

In a soft fork, old clients see new client structures as valid, but not necessarily the other way around. New clients can ignore old client blocks and tell them to fuck off. The "soft" part of the term is usually more of a technicality than an accurate description.

---

I just want to clarify many common misconceptions about soft forks.

Personally, I don't have any issues with BIP-361, but I think it's stupid that some idiots hate it because they mistakenly think it's a hard fork.

If you still want to hate it for some reason, hate it because it's a soft fork. Its Stage B rule change is incompatible with old clients, and that incompatibility is still valid as a soft fork.

Contrary to popular opinion, Bitcoin has had many hard-fork rule changes. Most of Bitcoin's hard fork rules changes went completely unnoticed over the years unless you were carefully following core devs updates.

There were at least 7 according to researcher JLopp. Except for the unintentional v0.80 one (that ironically was a buggy soft fork attempt), the hard fork ones didn't cause trouble or cause a chain/community split.

---

Soft forks are sometimes messier and bloated than hard forks

Imagine if software had to maintain backwards compatibility FOREVER:

• The Internet would be forced to support old insecure WEP routers
• Mario Odyssey would need to support running on every single version of Gameboy and Nintendo systems that existed, so they downgrade to 7 FPS and 16-bit color.
• Elden Ring would be forced to support Windows 3.11 and i386-era desktops, so it looks like Wolf 3D and loads across 250 floppy disks.
• Horses and wagons would still be allowed to use all roads and highways, creating dangerous traffic
• It would still be legal for doctors to practice bloodletting, mercury prescriptions, arsenic prescriptions, and drilling holes into skulls

Yeah, it would suck. At some point, new clients might choose to purposely start harming old clients to force them out of the system.

And that's how soft forks work. There would be so much technical bloat from needing to support so many old systems. And the software would crippled by low performance. Fortunately, hard forks are common in software development, and everyone benefits from modernizing and collectively upgrading to better versions.

There are a lot of misconceptions about soft and hard forks

• BOTH soft forks and hard forks can cause chain splits, but most don't.
• BOTH soft forks and hard forks can lead to incompatibility between old and new clients where new clients are completely intolerant of old client blocks.
• BOTH types can be small or big changes.
• BOTH types can be disruptive or permanent, but not necessarily.

There is so much overlap between the 2 types that difference is often more of a technicality.

Technical definition as per BIP-123:

• In a Hard Fork, structures that were invalid under the old rules become valid under the new rules. i.e. Rules become more loosened in a hard fork.
• In a Soft Fork, some structures that were valid under the old rules are no longer valid under the new rules. i.e. Rules become more restrictive in a soft fork.

Hard forks are generally fast, less complex, and don't lead to chain splits. Everyone coordinates to upgrade around the same time. Most modern blockchains operate this way, and long-lasting problems are extremely rare. Well-planned hard forks don't cause chain splits since the community chooses to upgrade together.

In contrast, soft forks can take forever to update. It took nearly a half decade for clients and exchanges to adopt Segwit and Taproot after they were released.

Why soft forks can be dangerous

They can cause reorgs and chain splits.

Not everyone is required to update. People running the old software can produce blocks that new clients choose to discard. So the new clients will ignore their blocks and reorg the chain. When this happens, the soft fork ultimately has a similar effect as a hard fork because the old clients can no longer produce blocks accepted by the new clients.

Example:

Imagine a soft fork update where old blocks containing P2PK transactions or ECDSA signatures are no longer valid under new rules. If 75% of miners supported the update while 25% didn't, the blocks produced by the 25% would be reorged by 75% of miners. There would be constant chain splits due to the soft fork.

So despite being a "soft" fork, there is still a "hard" cutoff because new clients can be intolerant of old clients.

Is that a bad thing? Not necessarily.

Both soft and hard forks can both have compatibility cutoffs. So stop stigmatizing hard forks for something that both types of forks can do (but that hard forks execute more cleanly).