pull down to refresh
reply
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.
reply
reply
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.
reply
Got it, that makes sense — sounds like this deployment is mixing aspects of BIP8 and BIP9 in a unique way. Appreciate the detailed breakdown
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....