Version

The version field is the first four bytes of a block header. Miners use it to signal that they are ready for a proposed soft fork, which is a change that old nodes still accept. It does not name the version of the miner's software. It works as a signal, so the network can agree on a safe date for a change.

Why did the version start as a plain number?

Until 2015, the version was a counter. Each upgrade raised it by one, and the new number told nodes which rules the block followed.

Version	Upgrade	Activated at
1	The original rules	block 0
2	BIP 34: block height in the coinbase	block 227,931
3	BIP 66: strict DER signatures	block 363,725
4	BIP 65: OP_CHECKLOCKTIMEVERIFY, a locktime check	block 388,381

An upgrade became mandatory once most recent blocks used the new number. For BIP 65, 950 of the last 1,000 blocks had to carry version 4 or higher. The system worked, but it had two drawbacks. Only one upgrade could be in progress at a time. And each upgrade closed off the older numbers for good.

Because of that, the minimum valid version is now 4. Bitcoin Core rejects any block with a lower version, since BIP 65 is active. Blocks that say 1, 2 or 3 are invalid today.

What are version bits?

BIP 9, written in 2015, turned the field into a bit field. Each bit can carry its own proposal, so several can run at the same time. The first upgrade to use it was the CSV change on bit 0, in 2016.

Here is how the field works:

• A block that uses version bits sets the top three bits to 001. That marks the field as version bits, and it leaves 29 bits for signals.
• Each of the other 29 bits, numbered 0 to 28 from the right, stands for one proposal.
• A miner sets a proposal's bit to say the miner is ready for it.
• Every proposal has a start time, a timeout and a threshold. Within each period of 2,016 blocks, if enough blocks set the bit, the upgrade locks in. It then activates after a further period.

Taproot shows the process. It used bit 2. To lock in, 90% of blocks in a period had to set that bit, which is 1,815 of 2,016. Signalling ran from 24 April 2021 to 11 August 2021. The upgrade activated at block 709,632, as BIP 341 records.

The three soft forks below used the first three bits:

Bit	Upgrade	Activated at
0	BIP 112: CHECKSEQUENCEVERIFY, a relative locktime check	block 419,328
1	BIP 141: SegWit	block 481,824
2	BIP 341: Taproot	block 709,632

Block 703,353 has version 0x20000004, which sets bit 2 and so signalled for Taproot. Block 974,000 has version 0x2008c000. Bits 14, 15 and 19 are set in that value. To see which proposal each bit belongs to, check the BIP 9 assignments list.

Why must the top bit stay 0?

Bitcoin Core reads the version as a signed 32-bit integer, as BIP 9 notes. If the top bit is 1, the number is negative. A negative version fails the minimum-version rule, so the block is invalid.

What is the default version?

The default is 0x20000000, which in binary is 0010 followed by zeros. It means the block uses version bits, and that no upgrade is being signalled.

Why do some blocks have strange version numbers?

Miners do not only use the version field for signals. Mining hardware changes bits 13 to 28 to make a new block header without rebuilding the transactions. The field then works as a second nonce. The range comes from BIP 320, a draft that sets those bits aside for general use. From about block 550,000, many headers carry bits that match no proposal, and most blocks since about 650,000 do. Read those bits as noise, not as a vote.

Bits get reused over the years. To learn what a bit meant at a given height, check that height against the BIP 9 list.

What comes next?

Next is previous block, the field that links each block to the one before it.