Bitcoin evolves through soft forks more often than hard forks: tightened rules that upgraded nodes enforce, while old nodes still see the chain as valid under older rules.
Why this matters
Builders who ship Script, Taproot, or Lightning features need to know how consensus changes actually land — and that “miners signaled” is not the whole story.
Soft vs hard
- Soft fork: new rules are a subset of old rules (more restrictive). Non-upgraded nodes may not understand new features but still follow the chain if upgraded miners/economically relevant nodes enforce.
- Hard fork: previously invalid blocks become valid (or incompatible validation). Risk of permanent split without coordinated migration.
Signaling and activation
Modern activations often use version bits (BIP9 family) or variants like Speedy Trial: miners set bits to signal readiness during a window; thresholds and timeouts decide lock-in.
Builder checklist
- Read the BIP activation parameters (start, timeout, threshold).
- Know which software must upgrade (policy vs consensus).
- Test on signet/regtest forks before assuming mainnet behavior.
Common mistakes
- Treating soft forks as “just a software update” with no wallet/relay impact
- Confusing policy (mempool standardness) with consensus validity
- Ignoring that light clients may see different security assumptions during upgrades