Soft Fork

Let V(old) be all blocks accepted by the pre-upgrade consensus rules. A change is a soft fork only if V(new) is contained in V(old): upgraded nodes reject an additional class of blocks, while compliant new blocks still pass old checks. The label describes compatibility of validity rules, not whether the change is small, uncontroversial or harmless. Increasing an old-visible limit or making an old-invalid spend valid would widen the set and normally require a hard fork. [Bitcoin Developer Guide — Consensus rule changes] [Bitcoin Optech — Soft fork activation]

An old full node can continue following the chain because upgraded miners normally produce blocks it recognizes as valid. It does not, however, enforce the added condition. If a more-work branch violates the new rule, the old node may accept it while upgraded nodes reject it. Users who need the new guarantee must upgrade their validating software; wallet compatibility, ability to receive and full consensus validation are not the same thing. [Bitcoin Developer Guide — Consensus rule changes] [BIP 341 — Taproot deployment]

Bitcoin has created subsets in several ways. BIP66 rejected non-strict DER signatures formerly accepted; BIP65 and BIP112 assigned conditions to NOP opcodes that old interpreters treated as successful no-operations; SegWit and Taproot assigned meaning to reserved witness versions that old nodes viewed as anyone-can-spend. The construction must also prevent old-valid data from bypassing the new check. SegWit therefore committed witness data through the coinbase while preserving the legacy-visible base-block rules. [BIP 66 — Strict DER signatures] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — Segregated Witness] [BIP 341 — Taproot deployment]

Code can contain dormant rules long before they govern mainnet. A proposal and reviewed implementation are not deployment; deployment parameters do not mean lock-in; lock-in schedules future enforcement; only ACTIVE means the rule is checked for that block. Each node computes the state from its own chain ancestry. A reorganization near a boundary can therefore require state recomputation, and different software or parameters can create incompatible enforcement. [BIP 9 — Version bits with timeout and delay] [Bitcoin Core — versionbits.cpp]

BIP9 assigns a deployment a name, version bit, start time and timeout. In its original mainnet form it observes 2,016-block retarget periods and locks in after at least 1,916 signaling blocks (95%) in a STARTED period, then waits one period before ACTIVE; otherwise it can become FAILED. The states are DEFINED, STARTED, LOCKED_IN, ACTIVE and FAILED. A block's state depends on ancestors, not its own version. Signaling is coordination, not a validity vote, and once locked in later signaling has no consensus effect. [BIP 9 — Version bits with timeout and delay]

Version bits reveal miner readiness and coordinate a safe transition; they do not grant miners permanent ownership of consensus. BIP8 replaces time with heights and can use lockinontimeout to require signaling in a final window. BIP148 instead had participating nodes reject non-signaling blocks for the SegWit deployment; BIP91 used a lower miner threshold to coordinate compatibility with that pressure. Any mandatory path can split the chain if enforcement, hash power and economic acceptance diverge, so activation design is itself a security trade-off. [BIP 8 — Version bits with lock-in by height] [BIP 148 — Mandatory activation of SegWit] [BIP 91 — Reduced threshold SegWit MASF] [Bitcoin Optech — Soft fork activation]

P2SH (BIP16) activated in 2012 using miner signaling embedded in coinbase and a timestamp boundary. BIP34 used block versions and a threshold to require height in coinbase. The same integer-version approach activated strict DER signatures in BIP66 and CHECKLOCKTIMEVERIFY in BIP65, but it consumed version values and allowed only one orderly deployment at a time. BIP9 introduced independent version bits; BIPs 68, 112 and 113 then activated together as relative lock-time/CSV rules at height 419,328 in 2016. [BIP 16 — Pay to Script Hash] [BIP 34 — Block v2, height in coinbase] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — Strict DER signatures] [BIP 112 — CHECKSEQUENCEVERIFY]

SegWit activated at height 481,824 in August 2017. Legacy nodes see transactions without witness data and treat version-0 witness programs as anyone-can-spend, while upgraded nodes verify the witness, new signature digest and malleability rules. A witness Merkle commitment in the coinbase prevents miners from changing or omitting witness data without detection by upgraded nodes. Weight accounting increased effective transaction capacity without making the legacy base block exceed its old one-megabyte limit. [BIP 141 — Segregated Witness]

Taproot's BIP341/BIP342 rules give version-1 witness programs key-path and script-path semantics using Schnorr signatures and Tapscript. Older nodes again see the reserved witness program as anyone-can-spend, which preserves the subset relationship but not full validation. Mainnet used a modified BIP9 'Speedy Trial': 1,815 of 2,016 signaling blocks (90%) could lock in, with minimum activation height 709,632. It activated there on 14 November 2021; the activation method and the rules it activated are distinct objects of review. [BIP 341 — Taproot deployment] [BIP 342 — Tapscript] [Bitcoin Core 0.21.1 release notes — Taproot deployment]

During BIP66 activation in July 2015, some miners signaled the new block version but performed insufficient validation of the parent they mined on. They extended an invalid block, producing a six-block invalid fork on 4 July and another shorter fork the next day. Upgraded validating nodes rejected those branches. The incident demonstrates that a version bit or version number is evidence supplied by a miner, not proof that its block template, parent and transactions were independently validated. [BIP 66 — Strict DER signatures] [Bitcoin.org — July 2015 BIP66 chain fork alert]

After ACTIVE, upgraded nodes reject violating blocks even if most hash power produces them; which branch gains work and economic use determines whether a persistent split results. Simply removing the restriction would re-admit blocks invalid under current rules and is therefore a hard-fork change; before activation, parameters or code can still be replaced by another coordinated release. Operators can inspect getdeploymentinfo/getblockchaininfo, the exact release and deployment parameters, activation height and logs, but explorer labels or signaling charts cannot substitute for local validation. [Bitcoin Developer Guide — Consensus rule changes] [Bitcoin Core — versionbits.cpp] [Bitcoin Core 0.21.1 release notes — Taproot deployment]