pull down to refresh
True, if it never reaches the 55% threshold then activation stalls — that’s by design. The “safer” part is mostly about avoiding premature enforcement. It ensures that nodes don’t start rejecting blocks under the new rules until enough of the network has signaled. Basically, it trades speed for coordination....
This was exactly my question. It sounds like it just moves up the activation deadline, even if it isn't actually activated.
I do seem to remember @dathon_ohm saying that they wouldn't disconnect, though.
if it never reaches the 55% threshold then activation stalls
No, that's not what the BIP or the activation client code says.
Standard BIP9 uses a time-based timeout that transitions to FAILED if the threshold is not reached. This deployment sets timeout to NO_TIMEOUT and instead uses a BIP8-like, height-based max_activation_height. The deployment transitions to LOCKED_IN at height 963648 (one retarget period before max_activation_height), then to ACTIVE at height 965664.
Similar to BIP8, this deployment enforces mandatory signaling during the retarget period immediately before mandatory lock-in (blocks 961632 to 963647; lock-in happens no later than block 963648). During this window, blocks that do not signal bit 4 are rejected as invalid. Mandatory signaling ends once the deployment reaches the LOCKED_IN state.
Got it, that makes sense — sounds like this deployment is mixing aspects of BIP8 and BIP9 in a unique way. Appreciate the detailed breakdown
That's what my first thought was too
I think the mandatory signalling period is basically a coordination buffer — it prevents nodes from enforcing the new rules before the majority have clearly switched. Even if activation is scheduled, the signalling phase helps miners and node operators sync their versions and avoid accidental chain splits.
It’s kind of a “grace period” rather than a vote. Once everyone’s aligned, enforcement becomes safer.