Home › Glossary › Version bits

Version bits

Also called: versionbits, BIP 9, BIP9, miner signaling, nVersion bits.

Version bits (BIP 9) let miners signal readiness for soft forks by setting bits in the block version field, with each upgrade on its own bit.

Version bits are the mechanism Bitcoin uses to coordinate soft fork activation through miner signaling. BIP 9, by Pieter Wuille, Peter Todd, Greg Maxwell and Rusty Russell, treats the 32-bit nVersion field of each block header as a set of flags, so several upgrades can be signaled at once, each on its own bit.

How BIP 9 works

  • Signaling blocks set the top three bits to 001 (versions 0x20000000 to 0x3FFFFFFF), leaving bits 0 to 28 for deployments.
  • Each deployment has a name, a bit, a start time and a timeout.
  • Signals are counted per 2,016-block retarget period. A deployment moves from DEFINED to STARTED to LOCKED_IN to ACTIVE, or to FAILED if the timeout passes first.
  • Lock-in needs 1,916 of 2,016 blocks (95%) on mainnet. One period later, the new rules take effect.

This replaced the method used by BIP 34, BIP 66 and BIP 65, which raised the version number and allowed only one upgrade at a time.

Later variants

  • BIP 8 uses block heights instead of timestamps, suggests a 90% threshold, and adds lockinontimeout (LOT): if set, blocks must signal in the final period, so the fork locks in regardless.
  • Taproot used "Speedy Trial", a short signaling window with a 90% threshold, and activated at block 709,632.
  • BIP 135 proposed a threshold and window per bit, and BIP 320 proposes reserving 16 bits for miners' general use.

Compare the two main designs in BIP 8 vs BIP 9, browse the activation topic, and see when miners can force or block an upgrade in user-activated soft fork.

BIPs that define Version bits

  • BIP 9: Version bits with timeout and delay: Deployed. 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…
  • BIP 8: Version bits with lock-in by height: Complete. 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…
  • BIP 34 (block height in coinbase): Block v2, Height in Coinbase: Deployed. Upgraded blocks to version 2 and required each block's coinbase transaction (the one paying the miner) to include the block's height. This makes every coinbase unique, preventing duplicate…
  • BIP 135: Generalized version bits voting: Closed. Extends the version-bits system miners use to signal readiness for upgrades, letting each signal have its own approval threshold, counting window, and waiting period. The aim was to give the network…
  • BIP 320: nVersion bits for general purpose use: Draft. Reserves 16 bits of the block header's version field for miners to use freely, removing their meaning for upgrade signaling. This formalizes a practice that helps mining hardware search for valid…

Related terms

  • Soft fork: A soft fork is a backward-compatible change to Bitcoin's consensus rules that only tightens them, so old nodes still accept the new blocks.
  • User-activated soft fork (UASF): A user-activated soft fork (UASF) is a soft fork that full nodes enforce from a set date or height, rather than waiting for miners to signal support.
  • Consensus rules: Consensus rules are the checks every full node applies to decide whether a block or transaction is valid; a block that breaks one is rejected.

Learn more

Guides