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

2

1 Answer 1

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.

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .