<p>New softforks are activated using <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="nofollow">BIP 9</a> (versionbits), which specifies the threshold requirements. The 95% threshold is inherited from the old <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow">BIP 34</a> (supermajority) softfork activation method.</p>

<p>A softfork with greater than 50% hashing power should always become the dominant chain because the upgraded miners will create a harder difficulty chain, and the non-upgraded nodes will be pulled onto that chain because it's still valid for them (soft-forks are backwards compatible). However, any non-upgraded miners may create blocks which are invalid under the new rules. Those blocks will be orphaned off the new chain. The lower the miner adoption rate, the higher this new orphan rate will be.</p>

<p>In reality, as soon as the threshold has been reached and the softfork is locked in, almost all miners will upgrade to the new rules.</p>

<p>The 95% rate is a very conservative threshold to ensure that there is widespread consensus for the new change.</p>

<blockquote>
  <p>miners who have not activated SegWit, will still confirm SegWit transactions </p>
</blockquote>

<p>This isn't true. If a miner hasn't activated SegWit, then it can't include SegWit transactions in its block (to include a SegWit transaction, it would need to include the witness data and commit to the merkle root of the witnesses in the coinbase transaction). <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow">BIP 141</a> documents all the consensus rule changes for SegWit.</p>

CC BY-SA 3.0
2016-10-26T15:12:57.330Z
Oh, hey there! Welcome to Bitcoin.SE. :)
Murch
CC BY-SA 3.0
2016-10-26T15:19:46.620Z
@jonnynewbs thank you. It sounds like I confused my use of miner and node. I will edit my question
254123179
CC BY-SA 3.0
2016-10-26T15:47:25.903Z
Non-segwit miners will not include segwit transactions, but for a different reason. The encoding of segwit scriptPubKeys is chosen in a way that makes it non-standard for all Core (and forks thereof) software since 0.10.
Pieter Wuille
CC BY-SA 3.0
2016-10-26T14:47:33.570Z
2016-10-26T14:47:33.570Z
jnewbery
<p>SegWit does not need to utilized by all (or even most) <em>nodes</em> in order to be used safely, but it must be adopted by almost all <em>miners</em> in order to successfully minimize or virtually eliminate the risk of forks or double spends after SegWit activation.  </p>

<p>My understanding is that (non mining) nodes that have not activated SegWit, will still consider SegWit transactions valid (because they see no requirement for a signature). However, if some miners includes SegWit transaction(s) in a block that other (non SegWit) mining node(s) reject double spends or forks <em>could</em> theoretically occur. Is that understanding correct?</p>

<p>With this risk in mind, exactly how was the 95% miner adoption level selected? Are there any available statistical simulations that estimate the chances of double spends or forks at a threshold more or less than 95%?</p>

CC BY-SA 3.0
2016-10-26T12:26:42.880Z
I thought if it was a soft fork it doesn't matter if they reject the block or not, it's just a normal block that they would be rejecting- is that right? since the rules are all basically the same, it's backwards compatible
smatthewenglish
<consensus><segregated-witness><bip9-version-bits>
How was the 95% miner adoption threshold determined?
254123179
# How was the 95% miner adoption threshold determined?

(Asked by: username_0 on 2016-10-26)

SegWit does not need to utilized by all (or even most) *nodes* in order to be used safely, but it must be adopted by almost all *miners* in order to successfully minimize or virtually eliminate the risk of forks or double spends after SegWit activation.

My understanding is that (non mining) nodes that have not activated SegWit, will still consider SegWit transactions valid (because they see no requirement for a signature). However, if some miners includes SegWit transaction(s) in a block that other (non SegWit) mining node(s) reject double spends or forks *could* theoretically occur. Is that understanding correct?

With this risk in mind, exactly how was the 95% miner adoption level selected? Are there any available statistical simulations that estimate the chances of double spends or forks at a threshold more or less than 95%?

**Tags:** consensus, segregated-witness, bip9-version-bits

> **Comments:**
> **username_1**: I thought if it was a soft fork it doesn't matter if they reject the block or not, it's just a normal block that they would be rejecting- is that right? since the rules are all basically the same, it's backwards compatible  

---

## 1 answers

### Answer by username_2 on 2016-10-26. Score: 4 | Accepted answer

New softforks are activated using [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) (versionbits), which specifies the threshold requirements. The 95% threshold is inherited from the old [BIP 34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) (supermajority) softfork activation method.

A softfork with greater than 50% hashing power should always become the dominant chain because the upgraded miners will create a harder difficulty chain, and the non-upgraded nodes will be pulled onto that chain because it's still valid for them (soft-forks are backwards compatible). However, any non-upgraded miners may create blocks which are invalid under the new rules. Those blocks will be orphaned off the new chain. The lower the miner adoption rate, the higher this new orphan rate will be.

In reality, as soon as the threshold has been reached and the softfork is locked in, almost all miners will upgrade to the new rules.

The 95% rate is a very conservative threshold to ensure that there is widespread consensus for the new change.

> miners who have not activated SegWit, will still confirm SegWit transactions

This isn't true. If a miner hasn't activated SegWit, then it can't include SegWit transactions in its block (to include a SegWit transaction, it would need to include the witness data and commit to the merkle root of the witnesses in the coinbase transaction). [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) documents all the consensus rule changes for SegWit.

> **Comments:**
> **username_3**: Oh, hey there! Welcome to Bitcoin.SE. :)  
> **username_0**: @jonnynewbs thank you. It sounds like I confused my use of miner and node. I will edit my question  
> **username_4**: Non-segwit miners will not include segwit transactions, but for a different reason. The encoding of segwit scriptPubKeys is chosen in a way that makes it non-standard for all Core (and forks thereof) software since 0.10.  

---

