0

Some miners set the nVersion field of the block header to 0x8000004. What were they signalling for? Is this an error? I have been through a lot of the BIP documentations, but cannot seem to find any references for it.

The first one occurred at block height 416,832. The last at block height 455,757.

https://www.blockchain.com/btc/block/416832

https://www.blockchain.com/btc/block/455757

Aman Saggu
  • 567
  • 2
  • 8
  • 3
    Does this answer your question? [Unusual Version Number in Blocks](https://bitcoin.stackexchange.com/questions/79273/unusual-version-number-in-blocks) – MCCCS Jun 19 '20 at 06:39
  • https://asicboost.dance – MCCCS Jun 19 '20 at 06:40

1 Answers1

1

This block signaled support for BitPay's adaptive Block Size Proposal and was mined by slush pool.

I asked slush this exact question on twitter back in 2016!

https://twitter.com/slush_pool/status/744461234389524480

Note that this answer is not entirely complete, because the BitPay proposal specifies:

Miners express their support for this BIP by setting the fifth-highest-bit in the block's 32-bit version number (0x08000000 in hex)

But these blocks as you note also set bit 2 (0x00000004) which was not addressed by slush in his answer.

During this era, several other soft-fork proposals were being floated around that (due to lack of coordination a.k.a. decentralization) collided on their BIP9 signals. One was Extension Blocks. I'm having trouble finding links but I believe also at that time there was Rootstock (RSK) proposal that defined bit 2 as the signal, and an anti-asicboost proposal by Greg Maxwell that also signalled bit 2.

pinhead
  • 4,932
  • 2
  • 23
  • 38