# Soft-fork activation mechanisms > Source: https://timechain.wiki/wiki/soft-fork-activation-mechanisms · TimechainWiki, the Bitcoin encyclopedia. (note · governance) > Bitcoin's soft-fork activation mechanisms are the technical-procedural framework for deploying backward-compatible protocol changes. Several have evolved: **BIP9** (Version Bits with Timeout and Delay) uses miner-signaling across a multi-week window; **BIP8** adds a mandatory-activation deadline if miner signaling stalls; **UASF / BIP148** coordinates activation through economic-node enforcement rather than miner signaling; **BIP91** combined a reduced-signaling threshold with BIP9-style coordination to actually activate SegWit; and **Speedy Trial** (used for Taproot 2021) combines miner signaling with a strict timeout. The landscape evolved through hard-learned experience: BIP9's pure miner-signaling proved insufficient when miner cooperation stalled during the Block Size Wars; BIP148 demonstrated that economic nodes can override miner stalling; Speedy Trial's compromise approach succeeded for Taproot. The LOT=true vs LOT=false debate during Taproot activation was the principal methodological dispute. Mechanism choice is itself a governance decision — different mechanisms imply different distributions of decision-making power between miners, economic nodes, and developers. --- ## Why this note matters Soft-fork activation mechanisms are the technical infrastructure through which Bitcoin's protocol actually evolves. Understanding what mechanisms exist, what they each imply about decision-making power, and how they have performed historically is the precondition for engaging Bitcoin's broader governance landscape. The mechanism choice for each specific upgrade (SegWit, Taproot, future covenant proposals) is a substantive governance decision rather than a technical detail. This note treats the technical-procedural mechanisms; [How upgrades happen](https://timechain.wiki/wiki/how-upgrades-happen.md) treats the broader social process; [Governance without governance](https://timechain.wiki/wiki/governance-without-governance.md) treats the structural framework. --- ## BIP9 — Version Bits with Timeout and Delay The original modern soft-fork activation mechanism. Introduced by Pieter Wuille, Peter Todd, and Greg Maxwell in 2015. **The mechanism.** Each soft fork is assigned a unique "version bit" in the block-header version field. During an activation period: 1. **Start time.** The activation window begins at a specified block height or median-time. 2. **Signaling.** Miners can signal support for the soft fork by setting the assigned version bit in their mined blocks. 3. **Threshold.** If 95% of blocks in a 2,016-block (~2-week) retargeting period set the version bit, the soft fork is "locked in." 4. **Activation delay.** After lock-in, there's typically a 2,016-block grace period before consensus rules actually change. This gives miners and node operators time to upgrade. 5. **Activation.** After the grace period, the soft fork's consensus rules become enforced. 6. **Timeout.** If 95% threshold isn't reached by a specified timeout date, the soft fork fails to activate. **The strengths.** BIP9 provides a clean miner-signaling-based activation mechanism. Miners signal support; if enough signal, activation proceeds; if not, activation fails. The mechanism is automated and transparent. **The weaknesses.** BIP9 gives miners effective veto power over soft forks. If miners (for whatever reason) don't reach the 95% threshold, activation fails regardless of broader community support. The Block Size Wars era (2015-2017) demonstrated this weakness: SegWit was supported by substantial portions of the community but stalled at ~50-60% miner signaling for an extended period before BIP148 forced activation. **Notable BIP9 activations.** BIP65 (CHECKLOCKTIMEVERIFY); BIP112 (CHECKSEQUENCEVERIFY); BIP141 (SegWit, eventually via BIP91 path); etc. --- ## BIP8 — Version Bits with Lock-in by Height A variant of BIP9 that includes a mandatory-activation mechanism. Introduced specifically to address BIP9's miner-veto problem. **The mechanism.** Identical to BIP9 during the signaling period. The key difference: at a specified "lock-in by height" deadline: - **If LOT=true.** Activation is mandatory at the deadline regardless of miner signaling. Blocks after the deadline must enforce the new rules; blocks that don't are invalid. - **If LOT=false.** Activation can fail at the deadline (no mandatory activation). The LOT (Lockinontimeout) parameter is the principal configurable element. LOT=true makes the soft fork mandatory; LOT=false makes it optional. **The strengths.** BIP8 addresses BIP9's miner-veto problem. If miners stall signaling, LOT=true forces activation at the deadline regardless. This produces a credible threat that miner-stalling will not prevent activation. **The weaknesses.** LOT=true creates the risk of a chain split if miners actively resist activation. Blocks mined that don't enforce the new rules after the deadline would be rejected by upgraded nodes but accepted by non-upgraded nodes — producing two competing chains. The chain-split risk is the principal concern about mandatory activation. **The LOT=true vs LOT=false debate.** During Taproot activation discussion (2020-2021), the community debated extensively whether LOT=true should be the default. LOT=true proponents argued that mandatory activation was the appropriate posture after the Block Size Wars experience. LOT=false proponents argued that chain-split risk was too high. The eventual compromise (Speedy Trial) used LOT=false but with a strict timeout. --- ## UASF / BIP148 — User-Activated Soft Fork An activation mechanism driven by economic-node consensus rather than miner signaling. Used to force SegWit activation in 2017 after BIP9 signaling stalled. **The mechanism.** Economic nodes (full nodes operated by users, exchanges, wallets, and other economic participants) collectively agree to reject any blocks from a specified date onward that don't signal support for the target soft fork. The mechanism doesn't require miner cooperation — it works by miner-economic-incentive: miners want their blocks accepted by economic nodes, so they signal support to ensure their blocks are accepted. **The BIP148 case study.** BIP148 specified that from August 1, 2017 onward, BIP148-running nodes would reject any block that didn't signal SegWit support. As August 1 approached, miner-signaling for SegWit climbed from ~50% to >90% as miners updated to ensure their blocks would be accepted. The intermediate BIP91 mechanism (proposed by James Hilliard) provided a compromise path that activated SegWit before the BIP148 deadline. **The strengths.** UASF demonstrates that economic-node consensus can override miner stalling. The mechanism makes the structural reality of Bitcoin's economic-incentive system operational: miners produce blocks that economic nodes accept; if economic nodes refuse to accept blocks, miners' revenue depends on signaling. The mechanism is the strongest available demonstration that miners are not the ultimate decision-makers in Bitcoin's governance. **The weaknesses.** UASF requires coordinated economic-node action. The coordination is operationally demanding and produces some chain-split risk during the activation period. UASF also creates a difficult precedent — once economic-node action has overridden miner signaling, the mechanism could in principle be deployed for less-clearly-supported upgrades. The precedent's appropriate scope is contested. **Notable UASF deployments.** BIP148 (SegWit activation, 2017). Various proposed UASF deployments for other upgrades have been discussed but not actually deployed. --- ## BIP91 — Reduced-threshold MASF The Miner-Activated Soft Fork mechanism that actually activated SegWit. Proposed by James Hilliard during the BIP148 activation window. **The mechanism.** BIP91 reduced the SegWit-activation threshold from 95% to 80% and shortened the lock-in period. It was designed as a compromise that would activate SegWit before the BIP148 deadline, allowing miners and nodes to converge on activation without the chain-split risk of pure BIP148 deployment. **The historical role.** BIP91 reached its 80% threshold on July 21, 2017; SegWit locked in on August 8, 2017; SegWit activated on August 24, 2017. BIP148 itself was never operationally triggered because BIP91 activated SegWit before the BIP148 deadline. **The lesson.** BIP91 demonstrated that compromise mechanisms can resolve activation deadlocks. The threat of BIP148 (UASF) created the pressure that motivated BIP91; BIP91 then provided the path to activation. --- ## Speedy Trial — the Taproot activation mechanism The mechanism used for Taproot activation in 2021. Combines BIP9-style miner-signaling with a strict timeout but uses LOT=false (no mandatory activation). **The mechanism.** Identical to BIP9 during a fixed 3-month signaling window (April 24 - August 11, 2021). If miners reached the 90% threshold in any 2,016-block period during the window, Taproot would lock in. After lock-in, a fixed grace period (until block 709,632, November 14, 2021) before activation. If miners didn't reach the threshold during the 3-month window, Taproot would not activate. **The historical role.** Taproot locked in on June 12, 2021 with 100% of mined blocks signaling support during the second retargeting period; Taproot activated on November 14, 2021 at block 709,632. The activation was non-contentious; miner signaling was strong. **The compromise structure.** Speedy Trial used LOT=false (no mandatory activation) — addressing the chain-split risk concern of LOT=true — but with a strict timeout that would prevent indefinite stalling. The compromise was acceptable to both LOT=true and LOT=false proponents. **The lesson.** Speedy Trial demonstrated that a fixed-window LOT=false approach can work when miner support is broad. The mechanism is less robust to miner stalling than LOT=true would be, but the chain-split risk is lower. For uncontroversial upgrades (Taproot was widely supported), the mechanism is adequate. --- ## The activation-mechanism choice as governance decision The choice of activation mechanism for each specific upgrade is itself a governance decision: **BIP9** implies miners have effective veto power. Appropriate when miner cooperation is expected and contention is low. **BIP8 LOT=true** implies miners do not have veto power and chain-split risk is acceptable to prevent stalling. Appropriate when contention is high and the upgrade has substantial community support. **BIP8 LOT=false / Speedy Trial** implies a compromise between miner cooperation and timeout deadlines. Appropriate when contention is moderate. **UASF / BIP148** implies economic-node consensus is the ultimate decision mechanism. Appropriate when miner stalling has been observed and economic-node-action is needed to break the deadlock. The mechanism choice for future upgrades (covenant proposals; post-quantum migration; etc.) is the principal current governance-conversation. The OP_CTV and BIP-300 debates have included substantial discussion of what activation mechanism would be appropriate. The empirical answer depends on the upgrade's specific dynamics. --- ## Tradeoffs and design choices **Miner-signaling vs economic-node-consensus.** The fundamental governance question. Miner-signaling is operationally clean but gives miners veto power. Economic-node-consensus reflects the actual structural decision-makers but is harder to coordinate. **Activation timeline vs deliberation time.** Faster activation timelines reduce the period of uncertainty but limit deliberation. Slower timelines allow broader engagement but extend uncertainty. The empirical answer varies by upgrade. **Chain-split risk vs mandatory-activation guarantee.** LOT=true provides activation guarantees but raises chain-split risk. LOT=false avoids chain-split risk but allows indefinite stalling. The compromise approaches (Speedy Trial; BIP91) try to navigate this. **The "consensus to change requires consensus to change" framing.** Bitcoin's design philosophy treats activation mechanisms themselves as requiring consensus. Disputed activation-mechanism choices (LOT=true vs LOT=false debate during Taproot) reflect this: the meta-governance question is itself subject to governance. **Substantive analytical critique** of activation-mechanism patterns lives in [Protocol-evolution constraints](https://timechain.wiki/wiki/protocol-evolution-constraints.md) (Criticisms). --- ## Open questions for further development - **What activation mechanism would be appropriate for OP_CTV / OP_CAT / other contested proposals?** The current covenant debates include extensive activation-mechanism discussion. See [OP_CAT and the covenants programmability debate](https://timechain.wiki/wiki/op-cat-and-the-covenants-programmability-debate.md). - **Would UASF mechanism be deployed for non-scaling upgrades?** The BIP148 precedent applies specifically to scaling; whether the precedent generalizes to other upgrade types is contested. - **How does the post-quantum migration interact with activation-mechanism choice?** The post-quantum migration is mandatory in the long run (the threat is real); the activation mechanism could be more aggressive than for optional upgrades. - **Can activation mechanisms be designed to better handle long-tail upgrade scenarios?** Current mechanisms work for binary activate/don't-activate decisions; more-complex coordination scenarios may require new mechanisms. --- ## Canonical sources for this note - **BIP9 specification** (github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) - **BIP8 specification** (github.com/bitcoin/bips/blob/master/bip-0008.mediawiki) - **BIP148 specification** (github.com/bitcoin/bips/blob/master/bip-0148.mediawiki) - **BIP91 specification** (github.com/bitcoin/bips/blob/master/bip-0091.mediawiki) - **Taproot Speedy Trial specification** - **[The Blocksize War (book) - Jonathan Bier](https://timechain.wiki/wiki/the-blocksize-war-book-jonathan-bier.md)** — historical context for BIP148 deployment - **Bitcoin Optech newsletter** — coverage of activation-mechanism debates - **bitcoindev mailing list archives** — primary source for activation-mechanism discussions --- ## Related notes - [Bitcoin Improvement Proposals](https://timechain.wiki/wiki/bitcoin-improvement-proposals.md) — BIP framework context - [Bitcoin Core](https://timechain.wiki/wiki/bitcoin-core.md) — implementation context - [Alternative implementations](https://timechain.wiki/wiki/alternative-implementations.md) — multi-implementation activation coordination - [Developer funding and incentives](https://timechain.wiki/wiki/developer-funding-and-incentives.md) — funding context - [How upgrades happen](https://timechain.wiki/wiki/how-upgrades-happen.md) — social process the activation mechanisms operate within - [Governance without governance](https://timechain.wiki/wiki/governance-without-governance.md) — structural framework - [Bitcoin Optech](https://timechain.wiki/wiki/bitcoin-optech.md) — developer-coordination platform - [SegWit upgrade](https://timechain.wiki/wiki/segwit-upgrade.md) — historical activation case study (home: scaling) - [Signature schemes in Bitcoin](https://timechain.wiki/wiki/signature-schemes-in-bitcoin.md) — Taproot activation context (home: technical) - [Soft forks and hard forks](https://timechain.wiki/wiki/soft-forks-and-hard-forks.md) — protocol-mechanism context (home: technical) - [Consensus rules](https://timechain.wiki/wiki/consensus-rules.md) — what activation mechanisms change (home: technical) - [OP_CAT and the covenants programmability debate](https://timechain.wiki/wiki/op-cat-and-the-covenants-programmability-debate.md) — current activation-mechanism debate (home: controversies) - [BIP-300 and the Drivechains debate](https://timechain.wiki/wiki/bip-300-and-the-drivechains-debate.md) — current activation-mechanism debate (home: controversies) - [The post-quantum migration debate](https://timechain.wiki/wiki/the-post-quantum-migration-debate.md) — long-horizon activation question (home: controversies) - [Protocol-evolution constraints](https://timechain.wiki/wiki/protocol-evolution-constraints.md) — analytical critique (home: criticisms) - [Block Size Wars - History](https://timechain.wiki/wiki/block-size-wars-history.md) — historical context (home: history) - [The Blocksize War (book) - Jonathan Bier](https://timechain.wiki/wiki/the-blocksize-war-book-jonathan-bier.md) — canonical historical text - [Pieter Wuille](https://timechain.wiki/wiki/pieter-wuille.md) — BIP9 co-author - [Peter Todd](https://timechain.wiki/wiki/peter-todd.md) — BIP9 co-author - [Greg Maxwell](https://timechain.wiki/wiki/greg-maxwell.md) — BIP9 co-author - [Adam Back](https://timechain.wiki/wiki/adam-back.md) — adjacent technical voice