What restrictions does the version field in the block header have?

Question

We are seeing a lot of funky values in the block version since blocks are getting mined using the version field for additional entropy. This made me wonder, what range of values are permitted in the version field?

Answer 1

nVersion is a 4-byte little-endian signed integer. Little-endianness means that the least significant byte is first. The order of bits in a byte remains the same.

I’m aware of the following restrictions:

• BIP65 requires blocks to have at least version 4.
• Since nVersion is a signed integer, setting the top bit would turn it negative.

Therefore, any bit pattern that does not set the top bit and sets at least one bit among positions 2…30 will be permitted.

Note that in the context of BIP-9-style deployments, the top three bits must be set to 001 and only in that case the remaining bits are interpreted as a bit vector where each position may signal readiness for a softfork proposal’s activation.

Let’s look at some examples in hexadecimal and binary:

Sign (topbit):

0b 00000000 00000000 00000000 ±0000000
                              ^
                              Sign (topbit)

Version 0, least and most significant bytes:

0x 00       00       00       00
0b 00000000 00000000 00000000 00000000
   ^______^                   ^______^
     LSB                        MSB

Version 1:

0x 01       00       00       00
0b 00000001 00000000 00000000 00000000

Version 4:

0x 04       00       00       00
0b 00000100 00000000 00000000 00000000

BIP-9 (not signaling):

0x 00       00       00       20
0b 00000000 00000000 00000000 00100000

Signaling for Taproot on bit 2:

0x 04       00       00       20
0b 00000100 00000000 00000000 00100000

Version of Block 779,960 (version field used for additional entropy):

0x 32       47       40       00
0b 00110010 01000111 01000000 00000000

The final example here is a block in which the version field is used as an additional source of randomness in the block header: it’s faster to change the version field instead of changing the extra nonce in the coinbase transaction because changing the version field will not require recalculating the left flank of the Merkle tree to update the Merkle root.