<p>A two week (2016 blocks) forced signaling phase has two major advantages.</p>
<p>Firstly, it offers a signal to the network that miners will be enforcing the soft fork rules in the next phase following the forced signaling. It is an imperfect signal as miners could follow the forced signaling and then not enforce the soft fork rules but it is better than nothing. To actually do this would suggest maliciousness or incompetence.</p>
<p>Secondly, it presents the possibility for mined blocks that aren't signaling being rejected <strong>in advance</strong> of when soft fork rules are supposed to be enforced. Not only does this provide an incentive for miners to signal (their mined blocks could get rejected otherwise) but it attempts to, temporarily until they agree to enforce the soft fork rules, kick them off the network so only miners that are enforcing the soft fork rules are on the network post activation. The whole point of soft fork activation is to attempt to coordinate across economic full nodes (and miners) a block height for when soft fork rules will be enforced from. We attempt to do everything possible to provide clarity to the network on what this block height is. In a scenario where miners have failed to meet the signaling threshold for a long period (e.g. a year) forced signaling is an important tool in the toolkit. If miners meet the signaling threshold in advance of the forced signaling it obviously is not needed.</p>
<p>Luke Dashjr stated on IRC:</p>
<blockquote>
<p>The primary purpose is to definitively indicate the soft fork is active on the chain. While it still relies on enforcement, this ensures there is no dispute over what the correct rules are. As a side effect this also makes it easy for any group of dissenters to reject the new rules. The intent of a soft fork should never be to literally force new rules (upon dissenters)</p>
</blockquote>
<p>(Luke is referring to dissent against the soft fork rather than dissent against the activation mechanism set in a Bitcoin protocol implementation.)</p>
<p>David Harding added that MUST_SIGNAL forced signaling has additional value in a scenario where there are both BIP 8(LOT=true) and BIP 8(LOT=false) nodes on the network. It ensures the soft fork activates for nodes setting LOT=false when the majority of the network is setting LOT=true.</p>
<blockquote>
<p>I run a node with LOT=false; everyone else runs a node with LOT=true. At block xxxxxx, y'all start enforcing taproots rules, but I never saw any signal, so I continue treating taproot transactions as anyone-can-spend, which is bad for me personally.  If there are a lot of people with LOT=false, it also makes it unclear whether taproot is really being enforced, increasing the risk that miners may try to steal funds sent to taproot outputs.</p>
</blockquote>
<p>In addition David Harding <a href="https://twitter.com/hrdng/status/1321167626018631681?s=20" rel="nofollow noreferrer">argues</a> that forced signaling is not particularly dangerous.</p>
<blockquote>
<p>What makes forced signaling so dangerous?  We had that with the BIP34, BIP66, and BIP65 forks.  Except for a hiccup with BIP66 due to spy mining, I don't think there was any problem. BIP8 forced signaling is also only required for a brief period, so any disruption should be short</p>
</blockquote>
<p>Comparing a forced signaling phase to a flag day was discussed further on this BIP <a href="https://github.com/bitcoin/bips/pull/1119" rel="nofollow noreferrer">PR</a>.</p>

CC BY-SA 4.0
2021-04-20T13:59:07.820Z
It should be noted that the new rules can be just as easily rejected without forced signalling by requiring that the block at activation height is invalid according to the rejected rules.


Can you elaborate what "no dispute over what the correct rules are" means? There can be dispute over what a signalling bit means just as well as there can be dispute over what a flag blockheight means.
nickler
CC BY-SA 4.0
2021-04-21T14:07:46.547Z
Thanks for the comment nickler. It is Luke's quote but my understanding of "correct rules" is whether the network is enforcing the soft fork rules or not. Indeed a forced signaling bit is not perfect in this respect but it is better than nothing. At least in my eyes following forced signaling but then not enforcing the soft fork rules afterwards demonstrates either maliciousness or incompetence. Although these are both possible you would expect in majority of cases that miners following forced signaling demonstrates that they will be enforcing the soft fork rules in an upcoming phase.
Michael Folkson
CC BY-SA 4.0
2021-02-13T15:03:52.730Z
2021-05-12T15:24:25.087Z
2021-05-12T15:24:25.087Z
Michael Folkson
<p>It depends highly on who you ask. Indeed, I (and several others) have argued that there is no reason whatsoever for forced-signaling. Greg Maxwell wrote a long and in-depth piece about why it provides no additional assurances beyond what any soft fork provides <a href="https://github.com/bitcoin/bips/pull/1119#issuecomment-835910470" rel="nofollow noreferrer">on GitHub</a>, which is likely of interest to anyone coming across this post. Ultimately, the point is all about &quot;when is a soft fork active&quot;. Probably the best resource on the subject is <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html" rel="nofollow noreferrer">Pieter Wuille's old post from 2015 on bitcoin-dev</a>, but to summarize, the answer is, largely &quot;when it is understood that the vast majority of economic nodes in the Bitcoin system are enforcing the rules via full node software which they run&quot;, in other words &quot;when full nodes are enforcing it&quot;.</p>
<p>Some confusion has entered the discussion as, in many past soft forks, we've utilized miner signaling to bridge the gap between old full nodes unaware of an upgrade and new full nodes enforcing the rules. Effectively, we've said &quot;the soft fork is active when new nodes have upgraded <em>and</em> miners have signaled readiness above a certain threshold&quot; - ultimately it's about nodes having upgraded and enforcing the rules, but there's nothing to stop us saying &quot;nodes only enforce the rules if miners upgrade&quot;. Similarly, there's nothing wrong with saying &quot;nodes always enforce the rules, because miners aren't doing something users want&quot;.</p>
<p>In general, the argument in favor of forced-signaling basically goes like this: &quot;if we start by assuming users are running software which interprets the signaling bit, then ensuring the bit is signaled on ensures that users are enforcing the rules&quot;. However, there's not a lot of reason to make that initial assumption. The reason we <em>do</em> use miner signaling in the first place is it reduces the risk of forks and reorgs visible to un-upgraded nodes - something that could expose some users to fund thefts due to double-spend. However, if we use forced-signaling, that advantage goes out the window, indeed, we get the exact opposite outcome - on day one of the fork, we immediately create reorgs visible to un-upgraded nodes, putting their ability to accept payment at risk.</p>

CC BY-SA 4.0
2021-05-10T19:01:41.427Z
2021-05-10T19:40:00.823Z
2021-05-10T19:40:00.823Z
Matt Corallo
<p>What is the benefit of forced signaling in a soft fork activation mechanism? e.g. the MUST_SIGNAL <a href="https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#state-transitions" rel="nofollow noreferrer">phase</a> in revised BIP 8.</p>
<p>I understand the benefits of setting lockinontimeout (LOT) to true (some of those benefits are described <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html" rel="nofollow noreferrer">here</a>) but why have a period of say two weeks when miners have to signal before the soft fork moves into the LOCKED_IN phase. Why not just define when that LOCKED_IN phase will begin (assuming miners fail to activate the soft fork before then) and ditch the MUST_SIGNAL phase?</p>
<p>Matt Corallo <a href="https://twitter.com/TheBlueMatt/status/1320740227762118663?s=20" rel="nofollow noreferrer">states</a> &quot;Forced signaling isn’t required for many flag day designs, and is the biggest single risk of any proposed feature for an uncontroversial activation.&quot;</p>

<soft-fork><taproot><activation-mechanism><bip8-version-bits>
What is the benefit of forced signaling in a soft fork activation mechanism?
Michael Folkson
# What is the benefit of forced signaling in a soft fork activation mechanism?

(Asked by: username_0 on 2021-02-13)

What is the benefit of forced signaling in a soft fork activation mechanism? e.g. the MUST\_SIGNAL [phase](https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#state-transitions) in revised BIP 8.

I understand the benefits of setting lockinontimeout (LOT) to true (some of those benefits are described [here](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html)) but why have a period of say two weeks when miners have to signal before the soft fork moves into the LOCKED\_IN phase. Why not just define when that LOCKED\_IN phase will begin (assuming miners fail to activate the soft fork before then) and ditch the MUST\_SIGNAL phase?

username_2 username_2 [states](https://twitter.com/TheBlueMatt/status/1320740227762118663?s=20) "Forced signaling isn’t required for many flag day designs, and is the biggest single risk of any proposed feature for an uncontroversial activation."

**Tags:** soft-fork, taproot, activation-mechanism, bip8-version-bits


---

## 2 answers

### Answer by username_0 on 2021-02-13. Score: 1 | Accepted answer

A two week (2016 blocks) forced signaling phase has two major advantages.

Firstly, it offers a signal to the network that miners will be enforcing the soft fork rules in the next phase following the forced signaling. It is an imperfect signal as miners could follow the forced signaling and then not enforce the soft fork rules but it is better than nothing. To actually do this would suggest maliciousness or incompetence.

Secondly, it presents the possibility for mined blocks that aren't signaling being rejected **in advance** of when soft fork rules are supposed to be enforced. Not only does this provide an incentive for miners to signal (their mined blocks could get rejected otherwise) but it attempts to, temporarily until they agree to enforce the soft fork rules, kick them off the network so only miners that are enforcing the soft fork rules are on the network post activation. The whole point of soft fork activation is to attempt to coordinate across economic full nodes (and miners) a block height for when soft fork rules will be enforced from. We attempt to do everything possible to provide clarity to the network on what this block height is. In a scenario where miners have failed to meet the signaling threshold for a long period (e.g. a year) forced signaling is an important tool in the toolkit. If miners meet the signaling threshold in advance of the forced signaling it obviously is not needed.

Luke Dashjr stated on IRC:

> The primary purpose is to definitively indicate the soft fork is active on the chain. While it still relies on enforcement, this ensures there is no dispute over what the correct rules are. As a side effect this also makes it easy for any group of dissenters to reject the new rules. The intent of a soft fork should never be to literally force new rules (upon dissenters)

(Luke is referring to dissent against the soft fork rather than dissent against the activation mechanism set in a Bitcoin protocol implementation.)

David Harding added that MUST\_SIGNAL forced signaling has additional value in a scenario where there are both BIP 8(LOT=true) and BIP 8(LOT=false) nodes on the network. It ensures the soft fork activates for nodes setting LOT=false when the majority of the network is setting LOT=true.

> I run a node with LOT=false; everyone else runs a node with LOT=true. At block xxxxxx, y'all start enforcing taproots rules, but I never saw any signal, so I continue treating taproot transactions as anyone-can-spend, which is bad for me personally. If there are a lot of people with LOT=false, it also makes it unclear whether taproot is really being enforced, increasing the risk that miners may try to steal funds sent to taproot outputs.

In addition David Harding [argues](https://twitter.com/hrdng/status/1321167626018631681?s=20) that forced signaling is not particularly dangerous.

> What makes forced signaling so dangerous? We had that with the BIP34, BIP66, and BIP65 forks. Except for a hiccup with BIP66 due to spy mining, I don't think there was any problem. BIP8 forced signaling is also only required for a brief period, so any disruption should be short

Comparing a forced signaling phase to a flag day was discussed further on this BIP [PR](https://github.com/bitcoin/bips/pull/1119).

> **Comments:**
> **username_1**: It should be noted that the new rules can be just as easily rejected without forced signalling by requiring that the block at activation height is invalid according to the rejected rules.   Can you elaborate what "no dispute over what the correct rules are" means? There can be dispute over what a signalling bit means just as well as there can be dispute over what a flag blockheight means.  
> **username_0**: Thanks for the comment username_1. It is Luke's quote but my understanding of "correct rules" is whether the network is enforcing the soft fork rules or not. Indeed a forced signaling bit is not perfect in this respect but it is better than nothing. At least in my eyes following forced signaling but then not enforcing the soft fork rules afterwards demonstrates either maliciousness or incompetence. Although these are both possible you would expect in majority of cases that miners following forced signaling demonstrates that they will be enforcing the soft fork rules in an upcoming phase.  

---

### Answer by username_2 on 2021-05-10. Score: 3

It depends highly on who you ask. Indeed, I (and several others) have argued that there is no reason whatsoever for forced-signaling. Greg Maxwell wrote a long and in-depth piece about why it provides no additional assurances beyond what any soft fork provides [on GitHub](https://github.com/bitcoin/bips/pull/1119#issuecomment-835910470), which is likely of interest to anyone coming across this post. Ultimately, the point is all about "when is a soft fork active". Probably the best resource on the subject is [Pieter Wuille's old post from 2015 on bitcoin-dev](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html), but to summarize, the answer is, largely "when it is understood that the vast majority of economic nodes in the Bitcoin system are enforcing the rules via full node software which they run", in other words "when full nodes are enforcing it".

Some confusion has entered the discussion as, in many past soft forks, we've utilized miner signaling to bridge the gap between old full nodes unaware of an upgrade and new full nodes enforcing the rules. Effectively, we've said "the soft fork is active when new nodes have upgraded *and* miners have signaled readiness above a certain threshold" - ultimately it's about nodes having upgraded and enforcing the rules, but there's nothing to stop us saying "nodes only enforce the rules if miners upgrade". Similarly, there's nothing wrong with saying "nodes always enforce the rules, because miners aren't doing something users want".

In general, the argument in favor of forced-signaling basically goes like this: "if we start by assuming users are running software which interprets the signaling bit, then ensuring the bit is signaled on ensures that users are enforcing the rules". However, there's not a lot of reason to make that initial assumption. The reason we *do* use miner signaling in the first place is it reduces the risk of forks and reorgs visible to un-upgraded nodes - something that could expose some users to fund thefts due to double-spend. However, if we use forced-signaling, that advantage goes out the window, indeed, we get the exact opposite outcome - on day one of the fork, we immediately create reorgs visible to un-upgraded nodes, putting their ability to accept payment at risk.


---

