Anthony Towns b6b5b92337 BIP8: clarify timeoutheight behaviour and requirements ...

When lockinontimeout is true, we don't transition directly from STARTED
to LOCKED_IN, so don't imply that we do.

If startheight or timeoutheight are not on a retarget boundary, they
behave as if they had been rounded up to the next retarget boundary,
so to keep things simple, require them to be at a boundary.

If timeoutheight is less than two retarget periods later than startheight,
behaviour when lockinontimeout is true (one retarget period of STARTED,
one of MUST_SIGNAL, one of LOCKED_IN, then ACTIVE) will not match
behaviour when lockinontimeout is false (one retarget period of STARTED,
then either LOCKED_IN or FAILED), so disallow that as well.

2020-10-17 17:24:15 +10:00

16 KiB

Raw Blame History

View Raw