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

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

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

• 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.
Mar 13 at 20:57
• As currently is, yes! But may change in the future. Mar 15 at 1:41
• Ok, thanks heaps. That is helpful.
– n.r.
Mar 15 at 14:01
• You may have a look at may answer bitcoin.stackexchange.com/a/112909/116982 :)
– n.r.
Mar 18 at 17:28

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