pull down to refresh
Actually, thinking more about it, and having had a look at BIP 9 again, the “flag day activation” description is not correct. lockinontimeout is implemented as a period of mandatory signaling in the last eligible difficulty period. If a minority of the hashrate were trying to enforce mandatory signaling then, there could be some reorgs in that difficulty period if any non-signaling blocks were reorged out by the soft forking hashrate. If the soft forking nodes were supported by a minority of the hashrate, they would already fork themselves off on a minority chain during the mandatory signaling rather than at activation, likely with very few or no reorgs, as they’d have to find two blocks before the rest of the network finds one.
I don't see that in the code, I think
My bad, I should have stated my assumptions, especially given that my assumption appears to have been incorrect.
BIP 9 does not have the lockinontimeout mechanism as it was introduced later by BIP 8. I assumed that RDTS was going to reuse the semantics of BIP 8 which enforce activation by mandatory signaling, but it appears that this assumption was incorrect, instead RDTS appears to simply switch to LOCKED_IN one difficulty period and a block before the max activation height, so a flag day activation was actually a fitting description.
Thanks for the summary. I suppose it's a good thing for Bitcoin to get tested in this way -- an aggressive minority pushing for a kinda bonkers soft fork.