BIP 9
Version bits with timeout and delay
Original title: Version bits with timeout and delay
- Status
- Deployed
- Type / Layer
- Informational
- Author
- Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
- Assigned
- Status verified
- Source
- github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
Summary
A mechanism for activating soft forks that allows several changes to be deployed in parallel. The earlier BIP34 approach compared a block's nVersion as an integer, so only one change could be in flight at a time and valid version numbers were permanently consumed. BIP9 instead reads nVersion as a bit vector, assigning each of bits 0 through 28 to track an independent change. Every deployment is parameterised by its bit, a start time and a timeout, and moves through the states DEFINED, STARTED, LOCKED_IN, ACTIVE and FAILED, transitioning only at retarget boundaries of 2016 blocks. If blocks setting the bit reach the threshold during a STARTED period (1916 out of 2016 on mainnet, about 95%), the deployment moves to LOCKED_IN and becomes ACTIVE one full period later; that delay gives nodes and miners which have not yet upgraded time to react before the rules change. If the threshold is never met before the timeout, the deployment ends in FAILED and the bit can be reused by another proposal.
Why it matters
It established the pattern later soft-fork deployments followed: miner signalling decides whether and when a change activates. It was used to deploy SegWit (BIP141), and Taproot was activated with Speedy Trial, a short-window variant of the same mechanism. The flip side — that a minority of hashrate can let a proposal expire simply by withholding signalling — drew criticism and motivated the design of BIP8.
Related BIPs
Related articles
This page carries a summary, not a translation. The original document is authoritative, and the metadata above — including Status — was transcribed from the bips repository on the verification date shown. Always consult the original when implementing or verifying.