How to calculate the version (eg. in Python)?

Question

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

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

Answer 2

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:

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:

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:

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:

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):