Soft Fork

Imagine Anna and Pavel each verifying Bitcoin on their own computer. Anna has updated her software; Pavel has not. An upgrade similar to BIP66 now requires a more strictly defined format for digital signatures, which prove authorization to spend particular bitcoins. Some previously accepted encodings are no longer allowed. A payment with a valid signature in the newly required format passes this check on both computers. But if the signature uses an encoding that was previously allowed and is now forbidden, Anna rejects it while Pavel may still accept it. We are assuming the payment meets all the other rules. That difference explains a Soft Fork: the new rules forbid additional cases without permitting anything the old rules forbade. As long as miners produce blocks that meet the tighter rules, both can keep following them. Pavel, however, is not checking the extra condition himself. A Soft Fork therefore makes it possible to change Bitcoin without every node upgrading simultaneously. It does not give old software the same checks as new software, nor does it create a second currency by itself. [1] [6]

A Full Node is a computer that independently checks Bitcoin's rules. When choosing between valid branches, it compares the cumulative work demonstrated by mining, not votes from their supporters. 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 branch with more accumulated work 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. A wallet being able to receive a payment or recognize an address format does not mean it checks every rule of the network. [1] [12]

A BIP is a numbered technical proposal. Publishing one does not change the network: software must be developed and checked, and its users must decide whether to run it. Mainnet is the main Bitcoin network, where real bitcoin changes hands. Activation determines when upgraded nodes on that network start requiring the new rule. Having code in a program is therefore different from using it to check blocks. In the activation procedures described here, lock-in means the condition for a later activation has been met; the rule need not be enforced yet. Only in the ACTIVE state does the node check it. Each node derives the state from earlier blocks in its own branch. If a reorganization changes that history near an activation boundary, the calculated state can change too. Two programs with different activation parameters may therefore disagree about which blocks to accept at the same time. [2] [15]

A miner builds a block on a preceding block, also called its parent. Failing to check that parent can waste work on a branch other nodes reject. 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. [6] [14]

To find out which rules your node actually uses, start with its software version and the information it returns itself. Depending on the release, getdeploymentinfo and getblockchaininfo provide information about deployments and the chain. Together with that release’s documentation, activation height and logs, they help distinguish a prepared rule from an active one. A web block explorer shows another service’s view; it does not prove what your own computer checks. Hashrate measures mining computation. It does not give miners permission to override your node’s rules: in the ACTIVE state, an upgraded node rejects a block that violates the new condition even if most mining power supports it. Whether a chain split persists also depends on the work accumulated by each branch and which branches people use economically. Simply removing the restriction would permit blocks that are currently invalid and would therefore be a hard-fork change. Before activation, parameters can be changed in a coordinated software release, but that change does not install itself on other people’s nodes. [1] [15] [16]

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. [1] [17]

Tighter rules can also introduce a feature. BIP66 specified strict DER, the encoding of signature data. BIP65 and BIP112 gave selected NOP commands, which previously enforced nothing, new time conditions for spending. SegWit introduced witness programs and validation data called witness, including signatures. Taproot later used their reserved version 1. Older nodes do not check the relevant new conditions; anyone-can-spend describes that limited view, not a way to bypass upgraded nodes and spend somebody else's coins. SegWit also cryptographically binds witness data to the block through a witness commitment. This binding is stored in the coinbase transaction, the first transaction containing the miner's reward, and preserves compatibility with the old base-block rules. [6] [5] [7] [8] [12]

A bit holds 0 or 1. Individual bits in nVersion, the block header’s version field, can signal a miner’s readiness. BIP9 assigns each deployment a name, a particular bit, a start time and a timeout. The original mainnet procedure evaluates periods of 2,016 blocks. At least 1,916 signaling blocks (95%) during STARTED move the next period into LOCKED_IN. One further waiting period follows before ACTIVE. If the condition is not met before the timeout, the procedure can end in FAILED. The initial state, before signaling starts, is called DEFINED. Each node calculates this sequence of states from earlier blocks. A block’s own nVersion therefore does not decide whether the new rule applies to it. Signaling helps coordinate the transition; it is not a validity vote on individual blocks. Once lock-in has been reached, later signals no longer change the outcome of this procedure. [2]

Versionbits lets miners signal readiness; it does not let them rewrite other nodes’ rules. BIP8 uses block heights rather than time boundaries. If lockinontimeout is true and the deployment has not yet locked in, the final period can enter MUST_SIGNAL, requiring signaling. BIP148 required participating nodes to reject blocks that did not signal SegWit; BIP91 used a lower miner-signaling threshold to coordinate this transition. If rule enforcement, hashrate and economic acceptance diverge, the chain can split. Choosing an activation mechanism therefore involves security trade-offs. [11] [9] [10] [17]

P2SH (BIP16) lets someone send funds to the hash of a script: a program containing the conditions for spending them later. When P2SH was introduced in 2012, signals in coinbase transactions helped establish miners’ readiness. The new checks themselves began applying from a specified block-timestamp boundary; signaling did not replace validation. Coinbase is the first transaction in a block, containing the miner’s reward. Later changes used the block version and signaling thresholds. BIP34 made it mandatory to record the block height, its position in the chain, in coinbase. BIP66 tightened the DER signature format, while BIP65 introduced CHECKLOCKTIMEVERIFY to enforce an earliest spending time or height. Repeatedly increasing the version number made independent upgrades difficult to deploy in parallel, so BIP9 introduced separate bits. BIPs 68, 112 and 113 activated together at height 419,328 in 2016, but address different aspects of time conditions. BIP68 introduces a relative wait from confirmation of the output being spent. BIP112 lets a script require that wait through CHECKSEQUENCEVERIFY, or CSV. BIP113 instead changes the clock used for a transaction’s absolute time lock: it uses Median Time Past, the median timestamp of the previous 11 blocks, rather than the timestamp of the block being evaluated. Activating together does not mean all three proposals introduce the same relative lock. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit activated at height 481,824 in August 2017. It separated witness validation data, such as signatures, from the part of a transaction used to calculate its identifier, the txid. Why does that matter? With the older encoding, someone could change the representation of a signature and thus the transaction identifier without changing who was paid or how much. This possibility is called malleability. Changing witness data alone does not change the txid; SegWit does not, however, fix inputs that still use the older format in this way. An old node sees the transaction without witness data and treats a version-0 witness program as anyone-can-spend. An upgraded node also checks the witness and the signature digest, a fingerprint of the data being signed. The witness commitment stored in a coinbase output cryptographically binds witness data to the block, allowing full validation to detect changes or omissions. Weight, the measure used to charge data against block capacity, increased effective capacity while keeping the base block visible to an old node within the original one-megabyte limit. [8]

Key-path spending uses a signature for the output key; script-path spending meets conditions in a revealed script. Schnorr is a signature scheme, and Tapscript is the language for these scripts. Taproot’s BIP341/BIP342 rules define key-path and script-path spending with Schnorr signatures and Tapscript for native SegWit outputs with a 32-byte version-1 witness program. 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. [12] [13] [16]