BIP8: Make signalling during LOCKED_IN recommended rather than mandatory#1020
Conversation
|
At present, the only time anyone has to potentially immediately update their consensus rules is if the last block in a STARTED period pushes signalling over the threshold, at which point the next block has to immediately signal or is invalid. There's grace periods for everything else -- enforcing the rules has the 2016 blocks of LOCKED_IN between knowing it's coming and it actually happening; and the first block of MUST_SIGNAL (hopefully) has a few months of grace between everyone deciding to set lockinontimeout=true and timeoutheight actually arriving. |
jonasnick
left a comment
jonasnick
left a comment
There was a problem hiding this comment.
ACK
this seems to be a remnant from before MUST_SIGNAL and there's no reason to not have a grace period
|
ACK. LOCKED_IN is an end state on the happy path. Once we reach this state there are no requirements in terms of signaling. Continued signaling is a nice to have but has no impact on the path taken or the end result. |
|
ACK this makes more sense |
|
ACK 9a119ce |
|
ACK |
3 similar comments
|
ACK |
|
ACK |
|
ACK |
|
ACK 9a119ce |
|
ACK 9a119ce |
14 participants
With the addition of the MUST_SIGNAL phase, signalling during LOCKED_IN is no longer needed for activation coordination, so drop it.