<p>There are two related risks: </p>

<ul>
<li><p><strong>Activating without a majority of hashpower supporting it over the long term.</strong></p>

<p>Let's use BIP 66 as an example. Imagine it had activated at the 95% threshold, but 30 minutes later, more than half of the miners reverted to the old implementation that doesn't support BIP66.</p>

<p>What you now have is a situation where nodes that enforce the new BIP66 rules will not come to consensus with nodes using older rules.</p>

<p>There's no perfect solution to this problem. As a miner, how can you prove that you won't change implementations after the activation point? The solution so far is to require 95% agreement to upgrade, on the theory that as long as less than 45% falsely signals, you'll be OK.</p></li>
<li><p><strong>Miners running old code may still produce blocks, fooling SPV/non-upgraded clients.</strong></p>

<p>At some point, someone will probably make a block that complies with the old rules, but not the new rules. Bitcoin Core won't do this by default, but it's probable that at least one miner will modify their code, or run some weird set of software, or even maliciously create a block to make a 51% attack easier.</p>

<p>Old nodes will accept this block, and try to build on it. Even if non-upgraded miners are in the minority, they're still going to manage to build chains of several blocks by pure chance sometimes. These will be orphaned eventually, but in the short term people may rely on them being valid, and be harmed by that.</p></li>
</ul>

<p>It's worth noting that lowering the threshold to 60% would likely still not activate segwit. Segwit signalling is currently about 30%.</p>

CC BY-SA 3.0
2017-03-26T00:51:12.013Z
Regarding your second point, note that the proposed segwit soft fork and the now-activated BIP68/112/113 soft fork before it were constructed in such a way that non-upgraded miners would not, by default, construct blocks that violate the new rules---therefore the only orphan risk is to miners who deliberately violate the new rules.  In the case of BIP68, anyone who wanted to use the new rules had to use transaction version 2, which older nodes would not relay or mine by default.  For segwit, using the new rules requires using a scriptSig that older nodes will not relay or mine by default.
David A. Harding
CC BY-SA 3.0
2017-03-26T18:35:12.220Z
@DavidA.Harding Good point, edited.
Nick ODell
CC BY-SA 3.0
2017-03-26T00:11:41.573Z
2017-03-26T18:34:28.677Z
2017-03-26T18:34:28.677Z
Nick ODell
<p>95% seems exceptionally conservative, especially given the evidence of vetoing by a subset of Bitcoin miners. What risks does, say, 60% over a longer activation period hold vs 95% for SegWit?</p>

CC BY-SA 3.0
2017-03-25T00:29:21.787Z
related: [What is the User Activated Softfork (UASF) proposal? How do its risks compare to hardforks?](http://bitcoin.stackexchange.com/q/51901/5406)
Murch
<segregated-witness><soft-fork><taproot><activation-mechanism>
What are the risks of a lower-than-95% activation threshold for soft forks (particularly SegWit)?
murty
# What are the risks of a lower-than-95% activation threshold for soft forks (particularly SegWit)?

(Asked by: username_0 on 2017-03-24)

95% seems exceptionally conservative, especially given the evidence of vetoing by a subset of Bitcoin miners. What risks does, say, 60% over a longer activation period hold vs 95% for SegWit?

**Tags:** segregated-witness, soft-fork, taproot, activation-mechanism

> **Comments:**
> **username_1**: related: [What is the User Activated Softfork (UASF) proposal? How do its risks compare to hardforks?](http://bitcoin.stackexchange.com/q/51901/5406)  

---

## 1 answers

### Answer by username_2 on 2017-03-26. Score: 2 | Accepted answer

There are two related risks:

* **Activating without a majority of hashpower supporting it over the long term.**

  Let's use BIP 66 as an example. Imagine it had activated at the 95% threshold, but 30 minutes later, more than half of the miners reverted to the old implementation that doesn't support BIP66.

  What you now have is a situation where nodes that enforce the new BIP66 rules will not come to consensus with nodes using older rules.

  There's no perfect solution to this problem. As a miner, how can you prove that you won't change implementations after the activation point? The solution so far is to require 95% agreement to upgrade, on the theory that as long as less than 45% falsely signals, you'll be OK.
* **Miners running old code may still produce blocks, fooling SPV/non-upgraded clients.**

  At some point, someone will probably make a block that complies with the old rules, but not the new rules. Bitcoin Core won't do this by default, but it's probable that at least one miner will modify their code, or run some weird set of software, or even maliciously create a block to make a 51% attack easier.

  Old nodes will accept this block, and try to build on it. Even if non-upgraded miners are in the minority, they're still going to manage to build chains of several blocks by pure chance sometimes. These will be orphaned eventually, but in the short term people may rely on them being valid, and be harmed by that.

It's worth noting that lowering the threshold to 60% would likely still not activate segwit. Segwit signalling is currently about 30%.

> **Comments:**
> **username_3**: Regarding your second point, note that the proposed segwit soft fork and the now-activated BIP68/112/113 soft fork before it were constructed in such a way that non-upgraded miners would not, by default, construct blocks that violate the new rules---therefore the only orphan risk is to miners who deliberately violate the new rules.  In the case of BIP68, anyone who wanted to use the new rules had to use transaction version 2, which older nodes would not relay or mine by default.  For segwit, using the new rules requires using a scriptSig that older nodes will not relay or mine by default.  
> **username_2**: @username_3 Good point, edited.  

---

