What is the benefit of forced signaling in a soft fork activation mechanism? What is the benefit of forced signaling in a soft fork activation mechanism? e.g. the MUST_SIGNAL phase in revised BIP 8.
I understand the benefits of setting lockinontimeout (LOT) to true (some of those benefits are described here) 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?
Matt Corallo states &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;
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, 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 Pieter Wuille's old post from 2015 on bitcoin-dev, 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;.
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 and 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;.
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 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.