This message, valid between version/verack for peers with version >= 70017,
would allow establishing at the time of connection that no transactions will be
announced/requested between those peers.
e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2 BIP155: change when sendaddrv2 is to be sent (Vasil Dimov)
Pull request description:
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`.
ACKs for top commit:
MarcoFalke:
ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2
harding:
ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2
jnewbery:
ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2
laanwj:
re-ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2
jonatack:
ACK e549ed3
hebasto:
ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2, I believe that the establishing of connection invariants in a such manner--in response to the `version` and prior to sending the `verack`--is the right way both for new `addrv2` message and for other future features.
Tree-SHA512: ec8c40a7f857cc8b7df10812cb34d526299b6908b06049dfea24e25d830fc2d01bf4c052e9e4cd575ce4a1b93032cbe27323a390fe7fb90803a5975dd363d150
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).