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

0

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.

| improve this answer | |

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.