SOFT / HARDSOURCE-LED COMPARISONS
Soft Fork vs. Hard Fork
Examine changes to validity rules, compatibility of non-upgraded nodes and risks of activation or a network split.
Soft Fork tightens rules so blocks valid under the new rules also satisfy old checks. Hard Fork also permits some blocks that old rules reject. The distinction describes compatibility, not a change's size or political support.
02The differences that matter
New rules exclude some previously permitted blocks. A block satisfying the new rules remains compatible with the old ones.
New rules admit at least some previously invalid blocks. An old node rejects such a block even with substantial cumulative work.
It can follow a compatible chain but does not enforce new restrictions. For SegWit, for example, it does not validate witness data.
Without changing rules it cannot validate and accept newly permitted, formerly prohibited blocks; it may remain on another branch or stop advancing.
It enforces additional rules once activation conditions are met. Signaling is no substitute for actual validation.
It enforces the new rule set according to its activation. Upgrading one node does not change other participants' rules.
Disagreement on activation or enforcement can produce different branches. Backward compatibility alone does not guarantee a smooth transition.
A lasting split occurs if different groups continue maintaining incompatible chains. The change's name does not guarantee two viable networks.
A BIP describes a proposal; it is not automatic approval. BIP9, for example, distinguishes signaling, lock-in and active rules.
Publishing a BIP does not activate anything here either. Operators need to understand the specific transition rules and consequences of incompatibility.
Soft Fork does not guarantee the absence of a chain split, and Hard Fork does not automatically create a new coin. Activation, enforcement and whether different groups continue incompatible histories determine the outcome.
We compare consensus changes, not ordinary interface or mempool-policy updates. BIP9, BIP16 and BIP141 are concrete examples; their activation conditions are not universal rules for every proposal.