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`.
6ef71b344c BIP155: Small text improvements (Hennadii Stepanov)
562f1d7188 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 6ef71b344c
Tree-SHA512: b88c7dfeeda2a99cfe1042c9f4e7cbeb6047882bf97ce9c1dd5e1f4a30203a9a03702638cc4b6c3b573f6c0a05b73a5ca43a77352a5ca24a32d19be129f8b317
The Bitcoin Core source code has `VARINT` type which is different than
the "variable integer" format used all over the P2P protocol and also
for the "services" field in this BIP. The latter is called `CompactSize`
in some BIPs and also in the Bitcoin Core source code, thus use the word
`CompactSize` to refer to it and link to its documentation.
32 bit unsigned can represent time up to year 2106
(32 bit signed is limited to just 2038).
So, we don't need to have "time" encoded as variable integer which would
take 5 bytes instead of 4.
Change signaling of support for the new `addrv2` messages to be done via
a dedicated message `sendaddrv2` instead of protocol bump.
The drawback of using a protocol bump is that the protocol version is
not a bitmask and if a node wants to announce support for `addrv2` this
would imply support for all prior features included in that protocol
version.
* Increase the maximum length of an address from 32 to 512 bytes and
clarify that the entire message should be rejected if it contains
a longer address.
(from https://github.com/bitcoin/bips/pull/766#issuecomment-519248699)
* Remove a contradiction about unknown address types - "MUST ignore" VS
"MAY store and gossip".
* Recommend gossiping addresses for networks to which the node is not
currently connected to.
(from https://github.com/bitcoin/bips/pull/766#issuecomment-545067608)
* Clarify that the entire message should be rejected if it contains an
address with unexpected size (e.g. IPv4 address with length 5).
