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?
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.
nVersionis 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:
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
0x 01 00 00 00 0b 00000001 00000000 00000000 00000000
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.