Signalling readiness for upgrades

Diagram showing the location of the nonce field inside the block header and how the last 29 bits are used to signal readiness for soft forks.

The 4-byte version field in the block header is used by miners to signal readiness for proposed soft-forks.

Version numbers are used in software to signify upgrades or the addition of new features. However, bitcoin is decentralized, so there's no central authority to force everyone to upgrade to new versions of the software. Therefore, it's ideal if the majority of the network can agree to proposed changes in advance.

So the version field is basically used to "vote" for proposed upgrades to the software.

They're not actually votes though. Any majority of miners can start enforcing a new rule - they don't need to indicate it in blocks, or even tell anyone about it. What [the version field] does is prove a way to signal readiness, so that a safe and coordinated transition point can be found.
Pieter Wuille,

Version Numbers

Up until 2015, the version number was incremented to signal readiness for new for upgrades. This happened until the version number was 4:

These upgrades became permanent when 950 out of 1000 blocks over a given time period were mined using the new version number. And once those upgrades were active, all new blocks had to use the new version number (or greater).

This system works, but the drawback is that you can only signal for one change at a time.

Due to these upgrades, the required minimum version number for a block is now 0x00000004. Any version number below that will be rejected by nodes on the network.

Version Bits

In 2015 the version field changed to being used a bit field, which allows miners to signal for up to 29 proposed new features at the same time.

Different bits in the 32-bit (4-byte) version field can be designated at the same time to signal readiness for a different soft fork. So all you have to do to signal readiness for a specific upgrade is turn a specific bit "on" (i.e. set it to 1).

Tool Icon

Version Bits

Bit Field
4 bytes
  • Version Bits: Enabled

The following bits have been used for upgrades:

To use "version bits" for signalling, you have to set the first 3 bits to 0b001 (as specified in BIP 9). This is just a requirement that indicates that you're making use of the version field as a bit field for signalling. So this is why you can only signal for a maximum of 29 different upgrades at the same time (32 - 3 = 29 bits).

Each proposal has its own time period for signalling, where a specific number of blocks have to signal for the upgrade over a specific window for it to become activated. With the taproot upgrade for example, 90% of blocks over a 2016-block target adjustment period had to signal for the upgrade (starting on 24 April 2021 and ending 11 August 2021), which eventually did happen, and the deployment activated at block height 709,632.

You can view the past and current upgrades being voted for via bitcoin-cli getblockchaininfo.

A list of all the bit assignments for proposed upgrades can be found here, but I don't think it's frequently updated.


Here are some examples of version numbers you'll find in the history of the blockchain.

After around the block height 411,000 the version field starts being used as a bit field more frequently (as opposed to a simple number). This is why the version "numbers" look so much larger, because the first 3 bits now being set as 0b001.

Here are some "non-standard" version numbers that pop up every now and then:

Current Default

The default version in the block header is currently:


Which in hex is


This indicates that you're using "version bits" (i.e. the first 3 bits are set to 0b001), but without signalling for any proposed new features (all the other bits are set to zero).

The first bit in the version field can never be 1, as this would indicate a negative number, which would be invalid. This is because Bitcoin uses a custom encoding for uint256 values.

This bit cannot be set to 1, or the version will be invalid:


Extra Nonce

There are no restrictions on what values you can put in the version field (other than it must be a minimum of 0x00000004, and the first bit of each byte must not be 1), so miners sometimes use it as an extra nonce when mining.

This is why since around block height 600,000 (also before, but more so since then) you often see some "weird" version numbers in the block header that do not correspond to any proposed upgrades. For example:

Again, these version numbers are signalling for anything in particular; they've just been adjusted so the miner can continue hashing their current block without having to rebuild it completely.