<p>This block signaled support for <a href="https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki" rel="nofollow noreferrer">BitPay's adaptive Block Size Proposal</a> and was mined by slush pool.</p>
<p>I asked slush this exact question on twitter back in 2016!</p>
<p><a href="https://twitter.com/slush_pool/status/744461234389524480" rel="nofollow noreferrer">https://twitter.com/slush_pool/status/744461234389524480</a></p>
<p>Note that this answer is not entirely complete, because the BitPay proposal specifies:</p>
<blockquote>
<p>Miners express their support for this BIP by setting the
fifth-highest-bit in the block's 32-bit version number (<code>0x08000000</code> in
hex)</p>
</blockquote>
<p>But these blocks as you note also set bit 2 (<code>0x00000004</code>) which was not addressed by slush in his answer.</p>
<p>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 <a href="https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md#activation" rel="nofollow noreferrer">Extension Blocks</a>. 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.</p>

CC BY-SA 4.0
2020-06-19T14:29:59.200Z
2020-06-19T14:29:59.200Z
pinhead
<p>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.</p>
<p>The first one occurred at block height 416,832. The last at block height 455,757.</p>
<p><a href="https://www.blockchain.com/btc/block/416832" rel="nofollow noreferrer">https://www.blockchain.com/btc/block/416832</a></p>
<p><a href="https://www.blockchain.com/btc/block/455757" rel="nofollow noreferrer">https://www.blockchain.com/btc/block/455757</a></p>

CC BY-SA 4.0
2020-06-19T06:39:54.547Z
Does this answer your question? [Unusual Version Number in Blocks](https://bitcoin.stackexchange.com/questions/79273/unusual-version-number-in-blocks)
MCCCS
CC BY-SA 4.0
2020-06-19T06:40:01.037Z
https://asicboost.dance
MCCCS
<mining-theory><block><protocol><blockchain-fork><consensus>
Some miners set the nVersion field of the block header to 0x8000004. What were they signalling for? Was this an error?
Aman Saggu
# Some miners set the nVersion field of the block header to 0x8000004. What were they signalling for? Was this an error?

(Asked by: username_0 on 2020-06-19)

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>

**Tags:** mining-theory, block, protocol, blockchain-fork, consensus

> **Comments:**
> **username_1**: Does this answer your question? [Unusual Version Number in Blocks](https://bitcoin.stackexchange.com/questions/79273/unusual-version-number-in-blocks)  
> **username_1**: https://asicboost.dance  

---

## 1 answers

### Answer by username_2 on 2020-06-19. Score: 1 | Accepted answer

This block signaled support for [BitPay's adaptive Block Size Proposal](https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki) 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](https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md#activation). 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.


---

