<p>While the answer of @Davidson Souza lead me into the right direction, he probably accidentally confirmed a wrong assumption. And I still found it difficult to apply this to reality. So I want to answer my question thinking this is a little more descriptive:</p>
<p>First you should start seeing the version field as a 32 bit integer. The protocol says, that the last (most left) 4 bits have to be <code>0010</code>. So the version field should at least look like this:</p>
<p><a href="https://i.sstatic.net/63YBo.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/63YBo.png" alt="enter image description here" /></a></p>
<p>Now a miner can signal readiness for a soft fork proposal by just flipping specific bits. The protocol allows the first (most right) <strong>13 bits</strong> to be used for that. For example there's a soft fork BIPn0 that says, that the first (0 -&gt; first in binary is the most right, remember? ;)) may be flipped to show readiness. In reality that looks like this:</p>
<p><a href="https://i.sstatic.net/tOYqq.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/tOYqq.png" alt="enter image description here" /></a></p>
<p>That is pretty smart. Why? A miner can individually signal readiness for independent soft fork proposals. Image there are 12 soft forks out there, but the miner only supports 4 of them - I'm just randomly picking here - that's how it would look like:</p>
<p><a href="https://i.sstatic.net/X97KG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/X97KG.png" alt="enter image description here" /></a></p>
<p>Eventually, that leaves 16 bits open. That's the space the miner can use as additional search space to find a header hash below the target. So that gives you 2^16 additional values (not 2^24 as I assumed):</p>
<p><a href="https://i.sstatic.net/aURcz.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/aURcz.png" alt="enter image description here" /></a></p>

CC BY-SA 4.0
2022-03-17T21:52:53.587Z
2022-03-17T21:52:53.587Z
n.r.
<p>BIP-034 defined block version 2, so blocks should have versions greater or equal than 2, since it's little-endian, we expect something like <code>0x02000000</code>. However, miners can change the following values with almost no restrictions, so they may use it as entropy source for new nonce cycles without recomputing a Merkle root. Ideally, everything beyond the <code>0x02</code> is ASIC-BOOST or whatever crazy change in version bits. Moreover, some soft-fork methods like BIP-008 and BIP-009 use the version as a bit field. Taproot uses the bit <code>2</code>, so every taproot signaling block ends with a <code>0x04</code>.</p>

CC BY-SA 4.0
2022-03-13T20:57:30.567Z
Thank you, so in other words: The actual version is defined by one byte, it can go up to 0xFF (0d255). And there are three bytes left to increase the additional search space by 2^24 possible variations?
n.r.
CC BY-SA 4.0
2022-03-15T01:41:35.010Z
As currently is, yes! But may change in the future.
Davidson Souza
CC BY-SA 4.0
2022-03-18T17:28:21.820Z
You may have a look at may answer https://bitcoin.stackexchange.com/a/112909/116982 :)
n.r.
CC BY-SA 4.0
2022-03-13T19:05:42.277Z
2022-03-13T19:05:42.277Z
Davidson Souza
<p>I'm working through <a href="https://medium.com/fcats-blockchain-incubator/understanding-the-bitcoin-blockchain-header-a2b0db06b515" rel="nofollow noreferrer">this medium post</a> that describes all header fields of a block. The explanation of the version field is a little unclear for me.</p>
<p>For starters I'm trying to consider version = 1, as in the very beginning of the chain:</p>
<pre><code>version_int = 1
version_hex = hex(version_int)
# from my understanding I need to add value 0x100000000 to the version
# though I do not understand why, currently I'm just taking this as a given fact
version_hex_min = hex(int(0x100000000) + version_int)[-8:]
# of course I need the little endian notation:
version_hex_min_le = binascii.hexlify(binascii.unhexlify(version_hex)[::-1])
</code></pre>
<p>This gives me the little-endian based hex value:</p>
<pre><code>0x01000000
</code></pre>
<p>That I can obviously use to calculate the header hash for version 1.</p>
<p>When I <a href="https://blockstream.info/block/000000000000000000078c7ad45ab182796bbb419c361aa3eaffaa8ddd00d4f0?expand" rel="nofollow noreferrer">check the latest block headers</a>, I see a version like that:</p>
<pre><code>0x20002000
</code></pre>
<p>That would result in the big endian hex representation:</p>
<pre><code>0x00200020
</code></pre>
<p>And to an decimal int:</p>
<pre><code>2097184
</code></pre>
<p>How does that number refers to the actual and current version and how do I extract the extra information that the miner used for this so called &quot;overt ASIC boost&quot;?</p>

<mining-theory><python><block-header><bip9-version-bits>
How to calculate the version (eg. in Python)?
n.r.
# How to calculate the version (eg. in Python)?

(Asked by: username_0 on 2022-03-13)

I'm working through this medium post that describes all header fields of a block. The explanation of the version field is a little unclear for me.
For starters I'm trying to consider version = 1, as in the very beginning of the chain:
version_int = 1
version_hex = hex(version_int)
# from my understanding I need to add value 0x100000000 to the version
# though I do not understand why, currently I'm just taking this as a given fact
version_hex_min = hex(int(0x100000000) + version_int)[-8:]
# of course I need the little endian notation:
version_hex_min_le = binascii.hexlify(binascii.unhexlify(version_hex)[::-1])

This gives me the little-endian based hex value:
0x01000000

That I can obviously use to calculate the header hash for version 1.
When I check the latest block headers, I see a version like that:
0x20002000

That would result in the big endian hex representation:
0x00200020

And to an decimal int:
2097184

How does that number refers to the actual and current version and how do I extract the extra information that the miner used for this so called "overt ASIC boost"?

**Tags:** mining-theory, python, block-header, bip9-version-bits


---

## 2 answers

### Answer by username_0 on 2022-03-17. Score: 0 | Accepted answer

While the answer of @username_1 lead me into the right direction, he probably accidentally confirmed a wrong assumption. And I still found it difficult to apply this to reality. So I want to answer my question thinking this is a little more descriptive:

First you should start seeing the version field as a 32 bit integer. The protocol says, that the last (most left) 4 bits have to be `0010`. So the version field should at least look like this:

[![enter image description here](https://i.sstatic.net/63YBo.png)](https://i.sstatic.net/63YBo.png)

Now a miner can signal readiness for a soft fork proposal by just flipping specific bits. The protocol allows the first (most right) **13 bits** to be used for that. For example there's a soft fork BIPn0 that says, that the first (0 -> first in binary is the most right, remember? ;)) may be flipped to show readiness. In reality that looks like this:

[![enter image description here](https://i.sstatic.net/tOYqq.png)](https://i.sstatic.net/tOYqq.png)

That is pretty smart. Why? A miner can individually signal readiness for independent soft fork proposals. Image there are 12 soft forks out there, but the miner only supports 4 of them - I'm just randomly picking here - that's how it would look like:

[![enter image description here](https://i.sstatic.net/X97KG.png)](https://i.sstatic.net/X97KG.png)

Eventually, that leaves 16 bits open. That's the space the miner can use as additional search space to find a header hash below the target. So that gives you 2^16 additional values (not 2^24 as I assumed):

[![enter image description here](https://i.sstatic.net/aURcz.png)](https://i.sstatic.net/aURcz.png)


---

### Answer by username_1 on 2022-03-13. Score: 1

BIP-034 defined block version 2, so blocks should have versions greater or equal than 2, since it's little-endian, we expect something like `0x02000000`. However, miners can change the following values with almost no restrictions, so they may use it as entropy source for new nonce cycles without recomputing a Merkle root. Ideally, everything beyond the `0x02` is ASIC-BOOST or whatever crazy change in version bits. Moreover, some soft-fork methods like BIP-008 and BIP-009 use the version as a bit field. Taproot uses the bit `2`, so every taproot signaling block ends with a `0x04`.

> **Comments:**
> **username_0**: Thank you, so in other words: The actual version is defined by one byte, it can go up to 0xFF (0d255). And there are three bytes left to increase the additional search space by 2^24 possible variations?  
> **username_1**: As currently is, yes! But may change in the future.  
> **username_0**: You may have a look at may answer https://bitcoin.stackexchange.com/a/112909/116982 :)  

---

