BIP 8 vs BIP 9: soft fork activation methods
BIP 9 and BIP 8 both let miners signal readiness for a soft fork by setting a bit in the block version, but BIP 9 measures its window in timestamps and simply fails if too few blocks signal, while BIP 8 measures in block heights and adds an optional lockinontimeout setting that forces lock-in at the end of the window. BIP 9 activated CSV and SegWit; Taproot used a modified BIP 9 that borrowed ideas from BIP 8.
Updated · 4 min read
At a glance
| BIP 9 | BIP 8 | |
|---|---|---|
| Title | Version bits with timeout and delay | Version bits with lock-in by height |
| Status | Deployed | Complete |
| Type | Informational | Informational |
| Assigned | 2015-10-04 | 2017-02-01 |
| Authors | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Shaolin Fry, Luke Dashjr |
| In plain English | Lets miners signal readiness for several soft forks (backward-compatible rule upgrades) at once by setting individual bits in each block's version number. An upgrade locks in once enough blocks signal within a period, or expires after a timeout; SegWit was activated this way. | An alternative way to activate soft forks (backward-compatible rule upgrades) that measures time in block counts rather than clock timestamps. It also adds an option to guarantee activation at the end of the signaling window even if miners do not signal support. |
How BIP 9 works
BIP 9, by Pieter Wuille, Peter Todd, Greg Maxwell and Rusty Russell, turned the block header's version field into a set of signalling bits, known as version bits. Each deployment picks a bit (0 to 28), a start time and a timeout. To signal support, a block sets the top three version bits to 001 and the deployment's bit to 1.
States change only at the boundary of each 2,016-block retarget period. A deployment starts as DEFINED and becomes STARTED once the median time past reaches the start time. If at least 1,916 of the 2,016 blocks in a period signal (95%, or 75% on testnet), it becomes LOCKED_IN for one more period and then ACTIVE. If the timeout passes first, it is FAILED and the bit can later be reused. Because each soft fork has its own bit, several can be deployed in parallel, which the earlier version-number method of BIP 34, used again for BIP 65, couldn't do.
How BIP 8 differs
BIP 8, by Shaolin Fry and Luke Dashjr, describes itself as "an alternative to BIP9 that corrects for a number of perceived mistakes". It keeps version-bits signalling but changes two things:
- Block heights, not timestamps. The start, the timeout and a new minimum activation height are block heights, which advance by exactly one per block. BIP 8 argues block time "is somewhat unreliable" and that a sudden loss of hashrate could interfere with a late, timestamp-based activation.
- lockinontimeout (LOT). With LOT set to true and the threshold not yet reached, the last period before the timeout becomes MUST_SIGNAL. Once 2,016 minus the threshold blocks in that period have failed to signal, further non-signalling blocks are invalid, so the soft fork locks in by the timeout. With LOT false, BIP 8 fails at the timeout just as BIP 9 does.
BIP 8 suggests a 90% threshold (1,815 of 2,016 blocks) and lets a locked-in deployment wait until minimum_activation_height before it becomes active, giving nodes more time to upgrade.
BIP 8 vs BIP 9 compared
| BIP 9 | BIP 8 | |
|---|---|---|
| Start and timeout measured in | Median time past (timestamps) | Block heights |
| Threshold | 95% (1,916 of 2,016); 75% on testnet | A parameter; 90% (1,815 of 2,016) suggested |
| If the threshold isn't reached | FAILED at the timeout | FAILED, unless lockinontimeout is true |
| Forced lock-in option | No | Yes, a MUST_SIGNAL period when LOT is true |
| Minimum activation height | No; ACTIVE one period after lock-in | Yes, minimum_activation_height |
| States | DEFINED, STARTED, LOCKED_IN, ACTIVE, FAILED | The same plus MUST_SIGNAL |
| Signalling format | Top bits 001, deployment bits 0 to 28 |
The same |
How SegWit and Taproot were activated
- CSV (BIPs 68, 112 and 113) was deployed with BIP 9 using bit 0 and activated at block 419,328 in July 2016.
- SegWit (BIP 141) used BIP 9 bit 1, with a window from November 2016 to November 2017. It was locked in through BIP 91, a deployment with a reduced 80% threshold, while BIP 148, a user-activated soft fork by Shaolin Fry, would have rejected non-signalling blocks from 1 August 2017. SegWit activated at block 481,824 on 24 August 2017. Shaolin Fry is also BIP 8's first author, and LOT=true offers a similar mandatory-signalling mechanism inside a version-bits deployment.
- Taproot (BIP 341) was deployed, in BIP 341's words, using "BIP9 modified to use a lower threshold, with an additional min_activation_height parameter": bit 2, timestamps from 24 April to 11 August 2021, a 90% threshold of 1,815 blocks and a minimum activation height of 709,632, where it activated in November 2021. This deployment was known as Speedy Trial. BIP 343 specified a BIP 8 deployment with LOT=true that was designed to be compatible with it.
Which applies to you?
Activation methods matter to node operators, miners and anyone following a soft fork proposal, not to everyday wallet use. The choice of LOT is a policy question with arguments on both sides. BIP 343 argues that eventual mandatory signalling ensures miners "cannot prevent the activation of a desired feature with community consensus indefinitely". BIP 8 itself warns that nodes running LOT=true "may potentially follow a lower work chain" than other nodes for an extended period, and that such nodes may need to connect preferentially to each other. The soft forks guide covers the wider history of soft forks.
Frequently asked questions
What is the difference between BIP 8 and BIP 9?
Both use version bits for miner signalling. BIP 9 sets its start and timeout with block timestamps (median time past), uses a 95% threshold, and fails if the timeout passes. BIP 8 uses block heights, suggests a 90% threshold, adds a minimum activation height, and offers lockinontimeout, which can force lock-in through mandatory signalling at the end.
What does lockinontimeout (LOT) mean?
lockinontimeout is a BIP 8 parameter. With LOT=true, if miners haven't reached the threshold by the last period before the timeout, that period becomes MUST_SIGNAL and blocks that don't signal can be rejected, so the soft fork locks in anyway. With LOT=false, the deployment simply fails at the timeout, as under BIP 9.
How was Taproot activated?
Taproot used a modified BIP 9 deployment known as Speedy Trial: signalling on bit 2 between 24 April and 11 August 2021, a 90% threshold of 1,815 blocks per period, and a minimum activation height of block 709,632. The threshold was reached, and BIPs 340, 341 and 342 activated at block 709,632 on 14 November 2021.
How was SegWit activated?
SegWit was deployed with BIP 9 on bit 1, with a 95% threshold and a window starting 15 November 2016. In 2017, BIP 91 (a miner deployment with a reduced 80% threshold) and BIP 148 (a user-activated soft fork requiring signalling from 1 August 2017) both aimed to get it locked in. SegWit activated at block 481,824 on 24 August 2017.
Why does BIP 8 use block heights instead of timestamps?
BIP 8's authors argue that block time is somewhat unreliable and can be inaccurate, and that a sudden loss of hashrate could interfere with a timestamp-based deadline. Heights rise by exactly one per block, so start, timeout and activation points are predictable; BIP 8 requires them to fall on 2,016-block retarget boundaries.