Unusual Version Number in Blocks

4

I've noticed recently that some blocks contain version numbers that are not the traditional 0x10000000 or 0x20000000.

For example, this block, has a version number of 0x3FFFE000 instead of 0x20000000 like the previous block has.

From my understanding this will not affect the actual hash digest, since it will produce a valid hash regardless of what the version field is.

A quick search on the forum did not return any results, but I am going to take a slight guess that this has something to do with miner voting to show what the consensus is for a future change? If this is the case, does it really make sense due to mining pools being a majority of hash power anyways? (Instead of miners votes individually)

If my prediction is correct, is there some list that defines which proposal coordinates to a given version number?

Thanks

8

but I am going to take a slight guess that this has something to do with miner voting to show what the consensus is for a future change?

No. There are currently no active consensus change proposals.

These version numbers are likely due to a mining optimization known as ASICBOOST. This optimization is due to a quirk of SHA256 and Bitcoin's block header format.

ASICBOOST is a hardware level optimization for mining chips that allows them to be more power efficient. One of the methods for ASICBOOST is to modify the block version number. The other method is to change only the first 4 bytes of the merkle root, but that requires much more computation than just changing the version number.

Even though this is a hardware optimization, the software for ASICBOOST miners also need to be aware of this optimization. This is why only some pools produce these ASICBOOST blocks, and only some machines can be used to produce them.