<p>Early soft forks each had their own activation method included in the proposal which <a href="https://bitcoin.stackexchange.com/a/97047/5406">relied on flagdays or block version signaling</a>. The latter only allowed a single proposal to be considered concurrently as it relied on incrementing the block version.</p>
<p><a href="https://en.bitcoin.it/wiki/BIP_0009" rel="nofollow noreferrer">BIP9</a> proposed an activation standard which allowed multiple proposals to be considered at the same time. Soft forks that were activated using <a href="https://en.bitcoin.it/wiki/BIP_0009" rel="nofollow noreferrer">BIP9</a> were coordinated by having a supermajority of hash power signal readiness for the upgrade (traditionally 95%). Miners are tasked to assess the network's uptake of the proposal and signal readiness by setting specific bits in the version field of their blocks. The miners readiness signal is measured over the last difficulty period at each retargeting height. For example, the segwit soft fork and the <code>CHECKSEQUENCEVERIFY</code> soft fork that activated BIP68, BIP112, and BIP113 used BIP9-based activation.</p>
<p><a href="https://en.bitcoin.it/wiki/BIP_0008" rel="nofollow noreferrer">BIP8</a> is a variant and the successor of BIP9. BIP8 uses block heights rather than timestamps to bound the signaling window, and gives the <em>option</em> to either fail or lock-in the upgrade at the end of the signaling window. When <code>lockinontimeout: true</code> is set, nodes running the activation code only accept blocks that signal readiness in the last difficulty period before the <code>timeoutheight</code>. This forces the upgrade to lock-in to the end of the signaling window. In contrast, BIP9 would always fail after the signaling window passed without activation, so BIP9 worked equivalently to BIP8 with <code>lockinontimeout: false</code>.</p>
<p><a href="https://i.sstatic.net/IEmtu.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/IEmtu.png" alt="BIP8 state transition graph" /></a>
<sup>via <a href="https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki" rel="nofollow noreferrer">BIP8</a></sup></p>
<p>Per BIP8, a proposal would get activated via the following steps:</p>
<ol>
<li><p>The signaling period commences at <code>start_height</code> by switching from <code>DEFINED</code> to <code>STARTED</code>. The <code>start_height</code> would be set at least a month after release of the activation code. Note that the <code>timeout_height</code> must be the end of a difficulty epoch.</p>
</li>
<li><p>At each difficulty retargeting, every node running the activation code independently checks whether the signaling threshold was met in the concluded difficulty period. There are three possible state transactions from <code>STARTED</code>:</p>
<ol>
<li>If the threshold is not met at <code>timeout_height</code>, the
proposal settles in the final <code>FAILED</code> state at the end of the signaling period.</li>
<li>If the signaling threshold was met, the proposal transitions to the
<code>LOCKED_IN</code> state.</li>
<li>If the proposal forces activation via <code>lockinontimeout: true</code> and
the last difficulty epoch of the signaling period is reached with
the proposal in <code>STARTED</code> state, the proposal transitions to <code>MUST_SIGNAL</code>. This causes upgraded nodes to reject any blocks that don't signal readiness.</li>
</ol>
</li>
<li><p>The proposal remains in <code>LOCKED_IN</code>
state for one difficulty period and then transitions to the final <code>ACTIVE</code> state. Upgraded nodes now enforce the soft fork rules on the network.</p>
</li>
</ol>

CC BY-SA 4.0
2022-04-29T11:03:00.203Z
An activation threshold of 90% in BIP8 differs from 95% in BIP9. I think BIP8 is more likely to get activated than BIP9 because of this threshold. Do you know why and where this threshold numbers come from?
ogw_yuya
CC BY-SA 4.0
2022-04-29T18:37:50.647Z
@ogw_yuya: They're picked as parameters for an activation attempt, either BIP8 or BIP9 could use a threshold of 90% or 95%.
Murch
CC BY-SA 4.0
2020-12-10T17:21:44.063Z
2020-12-16T19:42:21.773Z
2020-12-16T19:42:21.773Z
Murch
<p>With Taproot on everyone's lips, people have started discussing activation approaches. The debate currently seems to favor BIP8. Previous soft forks used BIP9. How are the two related and what are the differences between the two?</p>

<soft-fork><bip9-version-bits><bip8-version-bits>
How do BIP8 and BIP9 differ, how are they alike?
Murch
# How do BIP8 and BIP9 differ, how are they alike?

(Asked by: username_0 on 2020-12-10)

With Taproot on everyone's lips, people have started discussing activation approaches. The debate currently seems to favor BIP8. Previous soft forks used BIP9. How are the two related and what are the differences between the two?

**Tags:** soft-fork, bip9-version-bits, bip8-version-bits


---

## 1 answers

### Answer by username_0 on 2020-12-10. Score: 8 | Accepted answer

Early soft forks each had their own activation method included in the proposal which [relied on flagdays or block version signaling](https://bitcoin.stackexchange.com/a/97047/5406). The latter only allowed a single proposal to be considered concurrently as it relied on incrementing the block version.

[BIP9](https://en.bitcoin.it/wiki/BIP_0009) proposed an activation standard which allowed multiple proposals to be considered at the same time. Soft forks that were activated using [BIP9](https://en.bitcoin.it/wiki/BIP_0009) were coordinated by having a supermajority of hash power signal readiness for the upgrade (traditionally 95%). Miners are tasked to assess the network's uptake of the proposal and signal readiness by setting specific bits in the version field of their blocks. The miners readiness signal is measured over the last difficulty period at each retargeting height. For example, the segwit soft fork and the `CHECKSEQUENCEVERIFY` soft fork that activated BIP68, BIP112, and BIP113 used BIP9-based activation.

[BIP8](https://en.bitcoin.it/wiki/BIP_0008) is a variant and the successor of BIP9. BIP8 uses block heights rather than timestamps to bound the signaling window, and gives the *option* to either fail or lock-in the upgrade at the end of the signaling window. When `lockinontimeout: true` is set, nodes running the activation code only accept blocks that signal readiness in the last difficulty period before the `timeoutheight`. This forces the upgrade to lock-in to the end of the signaling window. In contrast, BIP9 would always fail after the signaling window passed without activation, so BIP9 worked equivalently to BIP8 with `lockinontimeout: false`.

[![BIP8 state transition graph](https://i.sstatic.net/IEmtu.png)](https://i.sstatic.net/IEmtu.png)
via [BIP8](https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki)

Per BIP8, a proposal would get activated via the following steps:

1. The signaling period commences at `start_height` by switching from `DEFINED` to `STARTED`. The `start_height` would be set at least a month after release of the activation code. Note that the `timeout_height` must be the end of a difficulty epoch.
2. At each difficulty retargeting, every node running the activation code independently checks whether the signaling threshold was met in the concluded difficulty period. There are three possible state transactions from `STARTED`:

   1. If the threshold is not met at `timeout_height`, the
      proposal settles in the final `FAILED` state at the end of the signaling period.
   2. If the signaling threshold was met, the proposal transitions to the
      `LOCKED_IN` state.
   3. If the proposal forces activation via `lockinontimeout: true` and
      the last difficulty epoch of the signaling period is reached with
      the proposal in `STARTED` state, the proposal transitions to `MUST_SIGNAL`. This causes upgraded nodes to reject any blocks that don't signal readiness.
3. The proposal remains in `LOCKED_IN`
   state for one difficulty period and then transitions to the final `ACTIVE` state. Upgraded nodes now enforce the soft fork rules on the network.

> **Comments:**
> **username_1**: An activation threshold of 90% in BIP8 differs from 95% in BIP9. I think BIP8 is more likely to get activated than BIP9 because of this threshold. Do you know why and where this threshold numbers come from?  
> **username_0**: @username_1: They're picked as parameters for an activation attempt, either BIP8 or BIP9 could use a threshold of 90% or 95%.  

---

