[WIP][POC][DONOTMERGE] Flag Day ST Compatible Logic w/ Optional Mandatory Signalling #21721

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.

A further observation on MTP & period drift:

Suppose I have release A which is start = today, stop = 3 years, height = start + 6 years blocks nomando noflagday.

Suppose i have release B which is start = today, stop = 3 years - 2 periods expected time, height = start + 6 years blocks flagday mando

I chose years to pick something where there could be a large amount of drift, because the effect is essentially duration invariant.

Because of difficulty adjustments and such, the 2 periods expected time, as set today 3 years from when it will actually be looked at, should always almost certainly guarantee that B's transition to mandatory signalling happens in at least one signalling period before the other activates.

Assume that height is not yet reached and timeout hits: clients proceed in full consensus.

Assume that height is already reached and timeout hits: What happens in this case is that B transitions to LOCKED_IN for 1 period of mandatory signalling, and in the next period proceeds to Active. The users of client A transition to LOCKED_IN 1 period later, and then Active 1 period later.

This means that miners for 1 signalling period would be SPV mining as the rule is yet to be active (policy protects them here).

However, this is still relatively safe because of A miners to be on the chain that activated via B would still require B to have a majority of hashrate.

To modify this to be always in perfect lock step with A (and no handwave about SPV mining for just one period), OnTimeout could be modified to emit a MANDATORY_SIGNAL period before LOCKED_IN, so that A and B hit locked_in at the same time.

I think this is better discussed on the mailing list; the code doesn't seem like it adds much over saying "imagine we have flag to say timeout switches to ACTIVE independently of signalling, and make signalling mandatory for every block in LOCKED_IN" ?

Sure; more than happy to close.

Mostly useful to open here -- regardless of where discussion should take place -- as the mailing list is non-ideal for looking at patches. I've just seen it claimed that such a patch was not possible in some places, so I wanted to create a concrete example to point to.

I don't intend to open a mailing list discussion on this but if someone else does feel free to refer.