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.

0 files changed, 0 insertions, 0 deletions