<p><code>nVersion</code> 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.</p>
<p>I’m aware of the following restrictions:</p>
<ul>
<li>BIP65 requires blocks to have at least version 4.</li>
<li>Since <code>nVersion</code> is a signed integer, setting the top bit would turn it negative.</li>
</ul>
<p>Therefore, any bit pattern that does not set the top bit and sets at least one bit among positions 2…30 will be permitted.</p>
<p>Note that in the context of BIP-9-style deployments, the top three bits must be set to <code>001</code> 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.</p>
<p>Let’s look at some examples in hexadecimal and binary:</p>
<p>Sign (topbit):</p>
<pre><code>0b 00000000 00000000 00000000 ±0000000
                              ^
                              Sign (topbit)
</code></pre>
<p>Version 0, least and most significant bytes:</p>
<pre><code>0x 00       00       00       00
0b 00000000 00000000 00000000 00000000
   ^______^                   ^______^
     LSB                        MSB
</code></pre>
<p>Version 1:</p>
<pre><code>0x 01       00       00       00
0b 00000001 00000000 00000000 00000000
</code></pre>
<p>Version 4:</p>
<pre><code>0x 04       00       00       00
0b 00000100 00000000 00000000 00000000
</code></pre>
<p>BIP-9 (not signaling):</p>
<pre><code>0x 00       00       00       20
0b 00000000 00000000 00000000 00100000
</code></pre>
<p>Signaling for Taproot on bit 2:</p>
<pre><code>0x 04       00       00       20
0b 00000100 00000000 00000000 00100000
</code></pre>
<p>Version of Block 779,960 (version field used for additional entropy):</p>
<pre><code>0x 32       47       40       00
0b 00110010 01000111 01000000 00000000
</code></pre>
<p>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.</p>

CC BY-SA 4.0
2023-03-09T22:14:11.743Z
What is the purpose of the "Overt ASICBOOST" changing version numbers?
Poseidon
CC BY-SA 4.0
2023-03-09T22:30:56.803Z
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
CC BY-SA 4.0
2023-03-09T22:38:03.803Z
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
CC BY-SA 4.0
2023-03-09T22:49:04.997Z
Yes, as I write in my answer, blocks simply have to have a version greater than 3.
Murch
CC BY-SA 4.0
2023-03-09T14:32:20.603Z
2023-04-07T17:53:25.960Z
2023-04-07T17:53:25.960Z
Murch
<p>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?</p>

<block-header><bip9-version-bits>
What restrictions does the version field in the block header have?
Murch
# What restrictions does the version field in the block header have?

(Asked by: username_0 on 2023-03-09)

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?

**Tags:** block-header, bip9-version-bits


---

## 1 answers

### Answer by username_0 on 2023-03-09. Score: 9 | Accepted answer

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

> **Comments:**
> **username_1**: What is the purpose of the "Overt ASICBOOST" changing version numbers?  
> **username_0**: 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.  
> **username_1**: 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?  
> **username_0**: Yes, as I write in my answer, blocks simply have to have a version greater than 3.  

---

