Mandate to send `sendaddrv2` to the peer before sending our `verack`
to them.
This way we know that the peer does not support `addrv2` if we did not
receive `sendaddrv2` from them before receiving their `verack`.
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).
6ef71b344c51aebe1dab5ac47f87d8f926462a65 BIP155: Small text improvements (Hennadii Stepanov)
562f1d71883d1daa0dd5f438d25986fb18465800 BIP155: Mention SHA3-256 explicitly (Hennadii Stepanov)
Pull request description:
It seems better to clarify that `CHECKSUM` in Tor onion v3 address uses SHA3-256 hash function.
ACKs for top commit:
vasild:
ACK 6ef71b344
laanwj:
ACK 6ef71b344c51aebe1dab5ac47f87d8f926462a65
Tree-SHA512: b88c7dfeeda2a99cfe1042c9f4e7cbeb6047882bf97ce9c1dd5e1f4a30203a9a03702638cc4b6c3b573f6c0a05b73a5ca43a77352a5ca24a32d19be129f8b317
