<p>You're misinterpreting the rule.</p>
<p>It is not &quot;as soon as the 95% threshold is <em>ever</em> hit in a window of 1000, version 1 blocks are not valid anymore&quot;. That would indeed imply invalidating the old chain.</p>
<p>It is instead &quot;any block for which the 95% threshold holds within the 1000 blocks preceding it, cannot have version 1&quot;.</p>
<p>In fact, blockchain validity rules are <em>always</em> just a function of a block's contents and its ancestry, and cannot depend on what has been seen in descendants or other branches of the chain. Doing so is introducing a risk of forking between nodes which have and have not seen those branches.</p>

CC BY-SA 4.0
2024-07-01T18:48:00.143Z
2024-07-01T19:48:43.707Z
2024-07-01T19:48:43.707Z
Pieter Wuille
<p>This is the relevant code for bip34 soft fork:</p>
<pre><code>// Reject block.nVersion=1 blocks when 95% (75% on testnet) of the network has upgraded:
if (nVersion &lt; 2)
{
    if ((!fTestNet &amp;&amp; CBlockIndex::IsSuperMajority(2, pindexPrev, 950, 1000)) ||
        (fTestNet &amp;&amp; CBlockIndex::IsSuperMajority(2, pindexPrev, 75, 100)))
    {
        return error(&quot;AcceptBlock() : rejected nVersion=1 block&quot;);
    }
}
// Enforce block.nVersion=2 rule that the coinbase starts with serialized block height
if (nVersion &gt;= 2)
{
    // if 750 of the last 1,000 blocks are version 2 or greater (51/100 if testnet):
    if ((!fTestNet &amp;&amp; CBlockIndex::IsSuperMajority(2, pindexPrev, 750, 1000)) ||
        (fTestNet &amp;&amp; CBlockIndex::IsSuperMajority(2, pindexPrev, 51, 100)))
    {
        CScript expect = CScript() &lt;&lt; nHeight;
        if (!std::equal(expect.begin(), expect.end(), vtx[0].vin[0].scriptSig.begin()))
            return DoS(100, error(&quot;AcceptBlock() : block height mismatch in coinbase&quot;));
    }
}
</code></pre>
<p>This means the condition &quot;block version must be &gt;= 2&quot; only applies when the function IsSuperMajority() returns true, and this function only returns true when 950 blocks from the last 1000 blocks have version &gt;= 2.</p>
<p>So, a node validating a block prior to the bip34 activation will deem a v1 block as valid, since the function IsSuperMajority() will return false.</p>
<p>Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last v1 block. 950 blocks later, the function IsSuperMajority() started to return true which made v1 blocks invalid. The function IsSuperMajority() returns true ever since.</p>

CC BY-SA 4.0
2024-07-02T11:41:50.853Z
Great thanks, sorry cannot vote as insufficient rep
Crypto L Plate
CC BY-SA 4.0
2024-07-02T10:32:44.777Z
2024-07-02T18:32:15.203Z
2024-07-02T18:32:15.203Z
bordalix
<p>In Antonopolous’s Mastering Bitcoin 2nd Ed p263, it says in the example of the BIP-34 soft fork activation the following:</p>
<p>&quot;When 95% (950 of the most recent 1000 blocks) are version 2, version 1 blocks are no longer considered valid.&quot;</p>
<p>This seems to imply the existing blocks in the blockchain that were mined prior to BIP-34, which are version 1 blocks, would be deemed invalid by an upgraded node. Though, clearly that cannot have been the case.</p>
<p>So, is it the case that an upgraded node applies different validation rules to the existing blockchain (for example when it is rebuilding its local blockchain) than it does to new blocks arriving from other nodes after the soft fork activation, i.e. version 1 blocks in the existing blockchain are accepted but new blocks which are version 1 are rejected? Is that how it works?</p>

<consensus><soft-fork><mastering-bitcoin><activation>
Why does an activated soft fork not invalidate the blockchain?
Crypto L Plate
# Why does an activated soft fork not invalidate the blockchain?

(Asked by: username_0 on 2024-07-01)

In Antonopolous’s Mastering Bitcoin 2nd Ed p263, it says in the example of the BIP-34 soft fork activation the following:

"When 95% (950 of the most recent 1000 blocks) are version 2, version 1 blocks are no longer considered valid."

This seems to imply the existing blocks in the blockchain that were mined prior to BIP-34, which are version 1 blocks, would be deemed invalid by an upgraded node. Though, clearly that cannot have been the case.

So, is it the case that an upgraded node applies different validation rules to the existing blockchain (for example when it is rebuilding its local blockchain) than it does to new blocks arriving from other nodes after the soft fork activation, i.e. version 1 blocks in the existing blockchain are accepted but new blocks which are version 1 are rejected? Is that how it works?

**Tags:** consensus, soft-fork, mastering-bitcoin, activation


---

## 2 answers

### Answer by username_1 on 2024-07-01. Score: 3 | Accepted answer

You're misinterpreting the rule.

It is not "as soon as the 95% threshold is *ever* hit in a window of 1000, version 1 blocks are not valid anymore". That would indeed imply invalidating the old chain.

It is instead "any block for which the 95% threshold holds within the 1000 blocks preceding it, cannot have version 1".

In fact, blockchain validity rules are *always* just a function of a block's contents and its ancestry, and cannot depend on what has been seen in descendants or other branches of the chain. Doing so is introducing a risk of forking between nodes which have and have not seen those branches.


---

### Answer by username_2 on 2024-07-02. Score: 4

This is the relevant code for bip34 soft fork:

```
// Reject block.nVersion=1 blocks when 95% (75% on testnet) of the network has upgraded:
if (nVersion < 2)
{
    if ((!fTestNet && CBlockIndex::IsSuperMajority(2, pindexPrev, 950, 1000)) ||
        (fTestNet && CBlockIndex::IsSuperMajority(2, pindexPrev, 75, 100)))
    {
        return error("AcceptBlock() : rejected nVersion=1 block");
    }
}
// Enforce block.nVersion=2 rule that the coinbase starts with serialized block height
if (nVersion >= 2)
{
    // if 750 of the last 1,000 blocks are version 2 or greater (51/100 if testnet):
    if ((!fTestNet && CBlockIndex::IsSuperMajority(2, pindexPrev, 750, 1000)) ||
        (fTestNet && CBlockIndex::IsSuperMajority(2, pindexPrev, 51, 100)))
    {
        CScript expect = CScript() << nHeight;
        if (!std::equal(expect.begin(), expect.end(), vtx[0].vin[0].scriptSig.begin()))
            return DoS(100, error("AcceptBlock() : block height mismatch in coinbase"));
    }
}

```

This means the condition "block version must be >= 2" only applies when the function IsSuperMajority() returns true, and this function only returns true when 950 blocks from the last 1000 blocks have version >= 2.

So, a node validating a block prior to the bip34 activation will deem a v1 block as valid, since the function IsSuperMajority() will return false.

Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last v1 block. 950 blocks later, the function IsSuperMajority() started to return true which made v1 blocks invalid. The function IsSuperMajority() returns true ever since.

> **Comments:**
> **username_0**: Great thanks, sorry cannot vote as insufficient rep  

---

