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?

1 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.

  • What is the purpose of the "Overt ASICBOOST" changing version numbers?
    – Poseidon
    Mar 9 at 22:14
  • 1
    Changing the version field is quicker than changing the coinbase transaction and rehashing the left flank of the merkle tree, thus it’s a quicker way to generate more variants from a block template.
    – Murch
    Mar 9 at 22:30
  • So as long as they don't add the BIP-9 style 001 on the most significant bits, these different / random version bytes have no other consensus level implication?
    – Poseidon
    Mar 9 at 22:38
  • 1
    Yes, as I write in my answer, blocks simply have to have a version greater than 3.
    – Murch
    Mar 9 at 22:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.