The reconciliation protocol assumes using one role consistently. Since
it is irrelevant which one is which, we can imply that the initiator of
the P2P connection will assume the role of reconciliation initiator.
This protocol simplification will seep into the implementation.
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`.
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).
Vasil Dimov