1

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

2 Answers 2

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.

4
  • 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
  • 1
    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
0

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:

enter image description here

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

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.