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.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: soft vs hard, signaling vs users
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 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.
Loading diagram…
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
Done when: You can explain why a soft fork is “backward compatible” for non-upgraded nodes in one sentence.
Step 3 — Activation timeline brief (lab)
Pick CSV, SegWit, or Taproot. Write a one-page brief: proposal, signaling method, activation height/date, who had to upgrade, and one risk that was debated.
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
Done when: Lab evidence (brief + upgrade list + risk note) is complete.
Next lesson
Mining & Consensus — proof-of-work, difficulty, and who actually enforces the rules.