Using the same threshold for MUST_SIGNAL as STARTED means that any chain
that would have resulted in activation with lockinontimeout=false will
also result in activation with lockinontimeout=true (and vice-versa).
This reduces the ways in which a consensus split can occur, and avoids
a way in which miners could attempt to discourage users from setting
lockinontimeout=true.
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.
This removes the FAILING state and adds compulsory signalling during a
new MUST_SIGNAL phase during the last retarget period prior to the
timeout height.
This ensures that if a deployment occurs using bip8 with
lockinontimeout=false and timeoutheight=N, that a later deployment using
bip8 with lockinontimeout=true and timeoutheight=K, where K<N that any
chain where LOCKED_IN is reached prior to height K, will be accepted as
valid by nodes using either set of deployment parameters.
It also ensures that the soft-fork's changed rules are only enforced
on chain a retarget period after signalling indicates enforcement is
expected (which was not previously the case if the FAILING to ACTIVE
transition took place).
Anthony Towns