With the drama of BIP444 I've seen a lot of people confused about the nature of soft-fork vs hard-fork. This might help:
Back in the block size war we had a lot of similar confusion, mostly because it isn't really very clear cut. Some people talked about "evil soft forks" to try to get rid of the simplistic notion: "soft forks are much better and hard forks are much worse" which tends to persist (naturally). The problem is that whether a fork is contentious or not is *much more important* than whether it fits the "soft" or "hard" technical definition.
When a fork isn't contentious, then the soft vs hard distinction (restricting the ruleset or relaxing it) really matters a lot, because "passive" network participants (imagine a piece of hardware that will never get updated to a new bitcoin version, in the extreme) will be fine with the first and not with the second.
When a fork *is* contentious, and miners, following economic incentive, end up choosing different rulesets to support different bitcoin users, then the chain genuinely forks into two histories. The fact that one ruleset is more restrictive than the other is part of the story but doesn't change the fundamental point that we have a chain split. This of course did actually happen meaningfully with bitcoin-cash in 2017. The term "evil soft fork" was some people trying to shake others of the misconception that if a fork is "soft" it's not coercive and not forcing action on anyone; that's definitely not true *if the fork is contentious*.
#bitcoin
Thread
Login to reply
Replies (14)
From a protocol-governance standpoint, “if you want different rules, fork” is exactly how Bitcoin’s immune system is supposed to work. It’s not censorship, it’s voluntary divergence: consensus by exit, not coercion by vote.
Let’s make this explicit:
1. Bitcoin’s consensus norm
Bitcoin’s social contract isn’t majority rule; it’s individual sovereignty. Every node chooses which chain to follow. The overwhelming unwritten norm since 2017 (SegWit2x) is:
Protocol changes that alter core properties—block size, script rules, censorship neutrality—must attract overwhelming, near-unanimous opt-in consensus.
If a minority can’t persuade the majority, they’re free to fork. That’s how BCH, BSV, and other spinoffs emerged. BIP-444 violates that equilibrium by proposing restrictions without universal buy-in.
2. The “fork-off principle”
Any faction that wants to redefine Bitcoin’s scope—whether by expanding or contracting it—should bear the coordination cost of the fork, not impose it on everyone else.
In other words, “Don’t make the default chain pay for your moral panic.”
If they truly believe BIP-444 is essential, let them hard-fork into a “clean-chain” variant—call it BTC-Puritan—and see if market participants follow. The market will instantly settle the argument through price discovery and hash-rate migration.
3. Functional precedent
When miners and devs tried to push SegWit2x, the network’s spontaneous coordination (via UASF) demonstrated that sovereignty resides with validating nodes, not political majorities. BIP-444 supporters trying to push a “temporary censorship fork” would hit the same wall.
4. Philosophical coherence
Agency-centered perspective: freedom of use is an emergent property of voluntary systems. BIP-444 is coercive not because it restricts bytes, but because it unilaterally redefines legitimate agency on the chain. If you don’t like how others use block space, out-compete them economically or build a sidechain—don’t rewrite reality.
In short:
Yes. Let them fork off.
That’s not hostility—it’s protocol hygiene. The network that respects voluntary divergence remains antifragile; the one that enforces purity decays into bureaucracy.
That reads like LLM output. Whether it is or not hardly matters. It's correct, at the very least it's roughly correct.
Thank you for your perspective!
Was thinking about Luke‘s pov.
ODELL
this is bullshit for what its worth
sane people do not think luke or core should control bitcoin and fortunately neither do

View quoted note →

The paragraph "Softforks don't chain split.." might seem like it's disagreeing with what I'm saying, but it's not. It's expressing the same mechanics with a different emphasis. I don't disagree with that.
His "bcash is an altcoin with an airdrop" - that was his line iirc at the time, and I always thought that was unhelpful (and also rather typical of his dismissal of the reality of any conflict with his position). The point is that bcash *becomes* an altcoin or an airdrop after it becomes clear that it has fully failed to gain general economic consensus as "the" bitcoin. It isn't that *by definition*, before the market has decided.
His last paragraph is wrong and BIP444 is a disastrously bad idea imo. I strongly suspect it will not get anywhere. (Note that this does *not* mean I believe an attempt to soft fork a simple restriction on OP_RETURN would be a guaranteed fail, but BIP444 is not that).
I don’t get the thing with counter forking the softfork. What would that look like in case of segwit?
Softfork tightens the consensus rules, I suppose bip44 limits the opreturn.
To enforce that miners must agree to run a node that will enforce the new rules, and the majority of blocks need to signal that right?
How will he code the consensus rules change? He can't change core so he has to do it on knots, miners don't run knots or do they?
same will zap
If were to summarise, are you suggesting that we should be careful supporting BIP444? And furthermore, that you're against it?
>When a fork *is* contentious, and miners, following economic incentive, end up choosing different rulesets to support different bitcoin users, then the chain genuinely forks into two histories.
This is only true if the soft fork chain has the *minority* of hash power.
If and when the soft fork chain has the *majority*, the minority non-soft fork chain will be re-orged away, and there will be no (lasting) split.
And yet .. bcash still has hashrate 🤷♂️
That was a hard fork.
And the minority hash power would be economically incentivised to move to the other side to avoid being reorged. I don’t understand why we would get a split if the majority of miners are going with bip 444. Would it not require a URSF or some sort of code change from the anti 444 group to force a chain split? Am I missing something?
You’re right. (Could be as simple as using the invalidateblock command though.)
Doh .. yes of course 🤦♂️