Soft Fork

A soft fork is a Bitcoin consensus change that tightens the rules: things that were previously valid become invalid under the new rules, but anything valid under the new rules is also valid under the old. Older nodes that haven't upgraded still see new blocks as legitimate; they just don't enforce the new constraints themselves.

This is the backwards-compatible way to evolve Bitcoin's protocol. It contrasts with a hard fork, which loosens rules and creates an incompatible chain that old nodes reject.

Notable Bitcoin soft forks:

• BIP-16 (P2SH) - 2012. Added the P2SH address format.
• BIP-65 (CLTV) - 2015. Added OP_CHECKLOCKTIMEVERIFY for absolute locktimes in scripts.
• BIP-68/112/113 (CSV) - 2016. Added relative locktimes.
• BIP-141 (SegWit) - 2017. The big one; restructured witness data, fixed malleability, doubled effective block capacity.
• BIP-340/341/342 (Taproot) - 2021. Added Schnorr signatures, Taproot, and Tapscript.

Activation typically involves miner signaling: enough miners must signal readiness for the new rules in their block headers before the fork "locks in" and starts being enforced. The mechanism is defined in BIP-9 and its successors. After activation, nodes that haven't upgraded continue working but may accept blocks that violate the new rules - which is why genuinely majority-supported soft forks are essentially safe, while contested ones can create chain splits.

The soft-fork approach is conservative: Bitcoin can add features without forcing everyone to upgrade simultaneously. It's also part of why Bitcoin evolves slowly - any proposal has to satisfy a high bar of community + miner + economic-node consensus to actually activate. The full multi-stakeholder dynamic is what Bitcoin governance describes; soft forks are the most common shape that process takes when the goal is adding capability without splitting the network.