[WIP][POC][DONOTMERGE] Flag Day ST Compatible Logic w/ Optional Mandatory Signalling #21721
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Just posting this here for discussion to show ST/MTP compatibility with flag days. This shows 2 patches for deployment params that enable lock in on timeout and optional mandatory signalling in a manner compatible with the existing ST logic.
This is quite similar to how a LAST_CHANCE state could work, but I think a little simpler.
Note that the lock in on timeout in this case would likely not activate the current ST parameters, unless one were to choose a timeout period that was earlier that the existing deployment (otherwise the original clients transition to FAILED and the flag_day_on_timeout proceed to true). In most cases what we see suggested for use, however, is a UASF client with a much further out date than a ST client, so concern of overlap for drag along is minimal.
One difference with prior mandatory signalling proposals is that this requires mandatory signaling until the transition becomes active. Changing the state machine so that signaling is required only sometimes is additional complexity for uncertain benefit. During any LOCKED_IN period, thus we require signalling.
The main drawback for not having LAST_CHANCE window is that clients with otherwise identical params except flag_day_on_timeout + mando won't activate the rule. However, supposing that because of the mandatory signalling and following the most work chain that the flag_day_on_timeout clients must have a hashrate supermajority anyways for these clients, it seems safe and simple that they can just switch to a buried deployment client after the fact. The LAST_CHANCE state transition would only be relevant for clients which are flag_day_on_timeout = false and mandaotry_signalling= false, I chose not to implement it so that this can serve as a reference for what could be deployed against Core's Taproot RC1.
The mandatory signalling during LOCKED_IN rule is compatible with BIP9 by policy, which suggests miners continue to signal till ACTIVE.
I don't intend to personally deploy or use anything like this until it is clear that Taproot might not activate and there is no discernible reason why, but I thought this should post this now just for the sake of demonstrating the existence of possible alternative UASF plans in the future. I think I'd be most likely to run yesflag nomando in the future if I felt I needed a flag day client.