Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.
Sign up to join this community
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.
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 (
0x08000000in 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.
