Version bits

A version bit stands for one pending soft fork, tallied over a fixed window of blocks. BIP-9 offers bits 0 through 28, and a deployment locks in once 1,916 blocks in a 2,016 block period set its bit, or fails at a timeout suggested as one year. Reading those signals is how you know months ahead whether a feature your wallet wants is becoming a network rule.

How it works

Version bits run as a five state machine that every node computes for itself, once per retarget period, for every deployment it knows about.

The states are DEFINED, STARTED, LOCKED_IN, ACTIVE and FAILED. Every block inside a 2,016 block retarget period shares one state, so a transition can only land on a height that is a multiple of 2,016. A deployment leaves DEFINED for STARTED when the median time past of the previous block passes the configured start time, median time past being the median timestamp of a block and its ten predecessors.

Once STARTED, a node walks back over exactly 2,016 ancestors and counts the blocks whose top three version bits are 001 and whose deployment bit is set. Anything else counts as zero, so a miner running some other version scheme cannot signal by accident. Mainnet needs 1,916 of them, testnet 1,512. Miss the bar until the median time past passes the timeout and the deployment goes to FAILED permanently. BIP-9 suggests putting that timeout 31,536,000 seconds, one year, after the start time, so a stalled proposal releases its bit rather than blocking the queue forever.

One detail catches people out. A block's state never depends on its own version field, only on that of its ancestors, so a miner cannot vote for a rule and have the vote bind the block casting it. Pinning the top three bits to 001 also fixes a signalling block's version inside the range 0x20000000 to 0x3FFFFFFF, leaving the patterns 010 and 011 free for whatever mechanism eventually replaces version bits.

Bits are recycled rather than spent. Once a deployment activates or times out its bit can carry a later proposal, after a fallow pause BIP-9 recommends so that buggy software is caught first. The specification also asks nodes to track bits they do not recognise and warn loudly when an unknown deployment locks in, which is how un-upgraded software warns you that a rule it cannot enforce is coming.

Where you see it

Two deployments have run on bitcoin's mainnet under BIP-9's own parameters, and the BIP's deployment list tabulates both.

The first, named csv, took bit 0 with a start time of 2016-05-01 and an expiry of 2017-05-01, and became active at block 419,328. It bundled BIP-68, BIP-112 and BIP-113, three of the changes BIP-9 lists as making previously valid transactions invalid. The second, segwit, took bit 1 with a window running from 2016-11-15 to 2017-11-15, and became active at block 481,824, inside a deadline it could have missed.

The scheme is also visible in mining plumbing. BIP-9 extended the getblocktemplate call with a rules array naming the deployments already active, a vbavailable object mapping each pending deployment's name to its bit, and an optional vbrequired mask of bits the server requires. A pool reads those keys to decide what to signal, which is what turns a shipped release into a tracker percentage.

Version bits vs version 2 block

A version 2 block carries a counter in the version field; version bits carry a bit vector in the same four bytes. Under BIP-34 the field was compared as an integer, so one upgrade could be in flight at a time and every success permanently burned values a valid block could use. BIP-9 spells out the bill: after BIP-34, BIP-66 and BIP-65 only 0x7FFFFFFB version values were left, which caps any bit vector scheme at 30 independent deployments. Fixing the top three bits instead turned what remained into 29 lanes that run in parallel and can be reused.