People seem to talk about ideas like temporary soft forks or future rules when proposing Bitcoin changes. They sound clever, but fall apart once you apply Bitcoin's well-defined axioms and consensus terminology.
Soft fork: makes some previously valid blocks invalid. Tightens the rule set.
Hard fork: makes some previously invalid blocks valid. Broadens the rule set.
That's it. The distinction doesn't depend on social coordination, activation style, or whether a split happens. It's purely about rule validity.
As Eric Voskuil outlines in Cryptoeconomics: Fundamental Principles of Bitcoin, these are axiomatic definitions, not social ones.
A so-called "temporary" soft fork suggests you tighten validation rules for a while and later revert.
Here's what actually happens:
The initial tightening is a soft fork.
Reverting it (accepting previously invalid blocks again) is a hard fork.
That's a soft fork followed by a hard fork, not something temporary in consensus terms.
Changing the narrative doesn't change the mechanics.
Bitcoin consensus applies to what's being validated now. Rules that might activate later, or sit dormant in code, aren't part of consensus until nodes actually enforce them.
Validation only checks blocks under current rules.
You can't measure consensus on hypothetical future behavior.
When those future rules do activate, they either narrow or broaden validity. A soft or hard fork at that point, nothing in between.
A "future rule" isn't part of consensus because consensus is a present-tense process. Or as I've said elsewhere: "A future rule is not consensus."
Temporary soft fork -> soft fork now, hard fork later.
Future rule -> not part of consensus until it's active.
Consensus = what nodes enforce today, not what they might agree to tomorrow.
For clean definitions, see voskuil.org/cryptoeconomics
Bitcoin works because its rules are objective, not promises, not intentions, just validation logic.