user116982: 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"?

user109558: 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.

116982: <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>
 109558: <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>
