Bitcoin soft forks: every consensus upgrade and how it activated
A soft fork is a change that makes Bitcoin's consensus rules stricter, so every block valid under the new rules is still valid under the old ones and nodes that don't upgrade keep following the same chain. Bitcoin's major consensus upgrades have all been soft forks: P2SH in 2012, the timelock opcodes in 2015 and 2016, SegWit in 2017 and Taproot in 2021. This guide lists each one with its BIPs and activation height, and explains how the ways of activating them changed over time.
Updated · 8 min read
What is a soft fork?
Bitcoin's consensus rules decide which blocks and transactions are valid. A soft fork tightens those rules: something that used to be allowed becomes invalid, and nothing that used to be invalid becomes allowed. Because the new rules are a subset of the old ones, a node running old software accepts the blocks that upgraded nodes produce. It just doesn't check the new restrictions itself.
New features are added this way by giving meaning to things old nodes treat as "anything goes":
- No-op opcodes. BIP 65 turned
OP_NOP2intoOP_CHECKLOCKTIMEVERIFYand BIP 112 turnedOP_NOP3intoOP_CHECKSEQUENCEVERIFY. Old nodes still see a no-op; new nodes fail the script if the condition isn't met. - Outputs old nodes see as spendable by anyone. P2SH and SegWit witness programs look like scripts anyone could spend, so restricting how they are spent is a tightening.
- Reserved hooks. SegWit left witness versions 2 to 16 undefined, and Tapscript reserves
OP_SUCCESSxopcodes and unknown key types for future rules.
The catch is that old nodes rely on the upgraded majority to enforce the new rules. BIP 141 warns that non-upgraded wallets should be "wary of anyone-can-spend scripts", and node operators are encouraged to upgrade to validate everything themselves.
Soft fork vs hard fork
| Soft fork | Hard fork | |
|---|---|---|
| Rule change | Tightens: some valid things become invalid | Loosens: some invalid things become valid |
| Old nodes | Keep following the chain, without checking the new rules | Reject the new blocks and stay on a separate chain |
| Coordination | Needs most hash power to enforce, so old nodes don't see conflicting chains | Needs every node to upgrade, or the chain splits |
| Bitcoin examples | P2SH, CLTV, CSV, SegWit, Taproot | Proposals such as BIP 101 and BIP 109, never activated |
Unplanned splits can happen too. BIP 50 documents March 2013, when a database lock limit in versions before 0.8 made old nodes reject a large block that 0.8 nodes accepted, splitting the chain until miners downgraded to restore one chain. See the hard fork glossary entry.
Every Bitcoin soft fork, in order
These are the consensus soft forks with BIPs. Heights are from BIP 90 and the BIP texts. A few early rule changes, such as the 1 MB block size limit added in 2010, predate the BIP process.
| Year | Upgrade | BIPs | Activation method | Enforced from |
|---|---|---|---|---|
| 2012 | Pay to Script Hash | 16 | Miner poll, then flag date | Blocks timestamped from 1 April 2012 |
| 2012 | No duplicate transaction IDs | 30 | Flag date | Blocks after 15 March 2012 |
| 2013 | Block height in coinbase | 34 | Version number supermajority (v2) | Block 227,931 (March 2013) |
| 2015 | Strict DER signatures | 66 | Version number supermajority (v3) | Block 363,725 (July 2015) |
| 2015 | OP_CHECKLOCKTIMEVERIFY | 65 | Version number supermajority (v4) | Block 388,381 (December 2015) |
| 2016 | Relative timelocks (CSV) | 68, 112, 113 | BIP 9, bit 0 | Block 419,328 (July 2016) |
| 2017 | Segregated Witness | 141, 143, 147 | BIP 9, bit 1, with BIP 91 and BIP 148 | Block 481,824 (24 August 2017) |
| 2021 | Taproot | 340, 341, 342 | Speedy Trial, bit 2 | Block 709,632 (14 November 2021) |
BIP 30 was later applied to all blocks except two historic ones at heights 91,842 and 91,880 that already contained duplicates. The full list of rule changes, including proposals, is on the consensus topic page; the SegWit and Taproot guides cover the two biggest upgrades in depth.
BIP 42: the April Fools' soft fork that is real
BIP 42, by Pieter Wuille, is dated 1 April 2014 and written as a joke ("making Bitcoin's monetary supply finite" is called "a controversial change"). The bug it fixes is real. The original subsidy code shifted 50 BTC right by the number of halvings. After 64 halvings that shift is undefined behavior in C++, and on common platforms the reward would have jumped back to 50 BTC. BIP 42 proposes a soft fork that keeps the subsidy at zero forever, which the BIP jokingly dates to 1 April 2214. Bitcoin Core includes the fix, so the 21 million cap holds permanently rather than for a few centuries.
How soft forks are activated
A soft fork is safest when most hash power enforces it from the same block, so the way that moment is chosen has changed several times.
Flag days (2012)
BIP 16 by Gavin Andresen asked miners to put "/P2SH/" in their coinbase as a poll, then enforced the rules from a fixed date. BIP 30 used a plain date. BIP 148 later pointed back to this "predetermined flag day" as a precedent.
Version number supermajority (2012 to 2015)
BIP 34 introduced signaling through the block version. Blocks of the new version had to follow the new rule once 750 of the last 1,000 blocks used it, and old-version blocks became invalid at 950 of 1,000. BIP 66 and BIP 65 reused this with versions 3 and 4. Its downsides, listed in BIP 9: only one upgrade at a time, no way for a proposal to fail cleanly, and each upgrade permanently used up version numbers. Shortly after BIP 66 took effect in July 2015, some miners who signaled the new version without fully validating built on an invalid block, causing a brief chain split.
BIP 9: version bits with timeout (2016 to 2017)
BIP 9, by Pieter Wuille, Peter Todd, Greg Maxwell and Rusty Russell, treats 29 bits of the block version as independent signals. Each version bits deployment has a bit, a start time and a timeout. Every 2,016-block retarget period the bits are counted: with 95% (1,916 blocks) the deployment goes from STARTED to LOCKED_IN, and one period later to ACTIVE. If the timeout passes first it becomes FAILED. CSV used it in 2016 and SegWit in 2017.
User-activated soft forks: BIP 148 and BIP 91 (2017)
SegWit's signaling stayed well below 95% for months. BIP 148 by Shaolin Fry proposed a user-activated soft fork (UASF): from 1 August 2017, nodes running it would reject any block not signaling for SegWit. BIP 91 by James Hilliard let miners reach the same result with an 80% threshold over 336 blocks. BIP 91 activated in July 2017, SegWit locked in during August and activated in late August. The SegWit guide has the timeline.
BIP 8: lock-in on timeout
BIP 8, by Shaolin Fry and Luke Dashjr, uses block heights instead of timestamps and adds a lockinontimeout (LOT) parameter. With LOT=true, blocks must signal during the final period, so the soft fork locks in by the timeout height whether or not miners signaled earlier. It recommends a 90% threshold. Choosing between LOT=true and LOT=false was a central question in the Taproot activation discussions. See BIP 8 vs BIP 9.
Speedy Trial (2021)
Taproot used Speedy Trial, which BIP 343 attributes to Russell O'Connor, with an outline by David Harding. It is BIP 9 with three changes recorded in BIP 341: a short window (24 April to 11 August 2021), a 90% threshold (1,815 of 2,016 blocks), and a minimum activation height (709,632) that left months between lock-in and activation for nodes to upgrade. BIP 343 by Shinobius and Michael Folkson specified a compatible BIP 8 LOT=true deployment as a fallback; it wasn't needed.
| Mechanism | Used for | Threshold | If miners don't signal |
|---|---|---|---|
| Flag day | P2SH, BIP 30 | None (date-based) | Activates anyway |
| Version supermajority | BIPs 34, 66, 65 | 75% / 95% of 1,000 blocks | Waits indefinitely |
| BIP 9 | CSV, SegWit | 95% of 2,016 blocks | Fails at timeout |
| BIP 8, LOT=true | Proposed (BIP 343) | 90% recommended | Locks in at timeout |
| Speedy Trial | Taproot | 90% of 2,016 blocks | Fails after a short window |
All activation BIPs are on the activation topic page.
BIP 90: buried deployments
Once a soft fork is long settled, re-checking how it activated is wasted work. BIP 90 by Suhas Daftuar replaced the version-counting logic for BIPs 34, 66 and 65 with fixed heights (227,931, 363,725 and 388,381). Bitcoin Core later buried the CSV and SegWit deployments in the same way.
Proposed soft forks under discussion
The BIP repository also holds consensus changes that have not activated. A BIP being published says nothing about whether it will be adopted; each BIP page shows its current status, and this guide doesn't predict outcomes.
- Consensus cleanup. BIP 54 by Antoine Poinsot and Matt Corallo bundles fixes for the timewarp attack, a limit of 2,500 legacy signature operations per transaction to bound worst-case validation time, invalid 64-byte transactions (a Merkle tree weakness), and a coinbase locktime rule that makes duplicate-transaction checks unnecessary. BIP 53 by Chris Stewart covers the 64-byte rule on its own.
- Covenants and new opcodes. Proposals such as CTV (BIP 119), SIGHASH_ANYPREVOUT (BIP 118), OP_CAT (BIP 347) and CHECKSIGFROMSTACK (BIP 348) would restrict how coins can be spent next. The covenants guide compares them.
- Quantum resistance. BIP 360 proposes a Pay-to-Merkle-Root output type and BIP 361 a phased sunset of today's signatures. See the quantum guide.
- Data limits. BIP 110 by Dathon Ohm proposed a temporary, one-year soft fork limiting the size of data fields in transactions.
Everything currently deployed is listed under deployed BIPs.
Frequently asked questions
What is the difference between a soft fork and a hard fork?
A soft fork tightens the consensus rules, so blocks valid under the new rules are also valid to old nodes, which keep following the chain. A hard fork loosens the rules, so old nodes reject the new blocks and stay on their own chain unless they upgrade. Bitcoin's major consensus upgrades, including P2SH, SegWit and Taproot, have all been soft forks.
How many soft forks has Bitcoin had?
Counting upgrades with BIPs, eight: P2SH (BIP 16), duplicate-transaction rules (BIP 30), height in coinbase (BIP 34), strict DER signatures (BIP 66), CHECKLOCKTIMEVERIFY (BIP 65), the CSV package (BIPs 68, 112, 113), SegWit (BIPs 141, 143, 147) and Taproot (BIPs 340, 341, 342). BIP 42's subsidy fix only matters centuries from now, and a few earlier rule changes predate BIPs.
What is a UASF?
A user-activated soft fork (UASF) is one where nodes, rather than miner signaling alone, set when new rules are enforced. BIP 148 was the best-known example: from 1 August 2017 its nodes would have rejected blocks that did not signal for SegWit. BIP 8 with lock-in on timeout (LOT=true) is a more general version of the same idea.
What is Speedy Trial?
Speedy Trial is the activation method used for Taproot in 2021. It is BIP 9 version bits with a short signaling window (April to August 2021), a 90% threshold and a minimum activation height. Miners reached the threshold in June 2021 and Taproot activated at block 709,632 on 14 November 2021.
Do I need to upgrade my node for a soft fork?
No, an old node keeps working and follows the same chain after a soft fork. But it doesn't check the new rules, so it relies on the upgraded majority for them, and it may treat new kinds of outputs as spendable by anyone. Upgrading lets your node validate everything itself, which is why operators are encouraged to do it.