Merge bitcoin#1043: BIP155: change when sendaddrv2 is to be sent

e549ed3 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 e549ed3
  harding:
    ACK e549ed3
  jnewbery:
    ACK e549ed3
  laanwj:
    re-ACK e549ed3
  jonatack:
    ACK e549ed3
  hebasto:
    ACK e549ed3, 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

Author: laanwj

bip-0155.mediawiki

@@ -134,7 +134,7 @@ See the appendices for the address encodings to be used for the various networks
 
 Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2".
 
-<code>sendaddrv2</code> SHOULD be sent after receiving the <code>verack</code> message from the peer.
+The <code>sendaddrv2</code> message MUST only be sent in response to the <code>version</code> message from a peer and prior to sending the <code>verack</code> message.
 
 For older peers, that did not emit <code>sendaddrv2</code>, keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types.