1 files changed, 25 insertions, 25 deletions
diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
index 5914241..3e7b0d8 100644
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@@ -44,9 +44,8 @@ interpreted as described in RFC 2119<ref>[https://tools.ietf.org/html/rfc2119 RF
 
 The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>.
 It is serialized in the standard encoding for P2P messages.
-Its format is similar to the current <code>addr</code> message format
-<ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the 
-fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the time and services format has been changed to VARINT.
+Its format is similar to the current <code>addr</code> message format, with the difference that the 
+fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize].
 
 This means that the message contains a serialized <code>std::vector</code> of the following structure:
 
@@ -55,13 +54,13 @@ This means that the message contains a serialized <code>std::vector</code> of th
 !Name
 !Description
 |-
-| <code>VARINT</code> (unsigned)
+| <code>uint32_t</code>
 | <code>time</code>
-| Time that this node was last seen as connected to the network. A time in Unix epoch time format, up to 64 bits wide.
+| Time that this node was last seen as connected to the network. A time in Unix epoch time format.
 |-
-| <code>VARINT</code> (unsigned)
+| <code>CompactSize</code>
 | <code>services</code>
-| Service bits. A 64-wide bit field.
+| Service bits. A bit field that is 64 bits wide, encoded in [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize].
 |-
 | <code>uint8_t</code>
 | <code>networkID</code>
@@ -78,8 +77,8 @@ This means that the message contains a serialized <code>std::vector</code> of th
 
 One message can contain up to 1,000 addresses. Clients SHOULD reject messages with more addresses.
 
-Field <code>addr</code> has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject
-longer addresses.
+Field <code>addr</code> has a variable length, with a maximum of 512 bytes (4096 bits).
+Clients SHOULD reject messages with longer addresses, irrespective of the network ID.
 
 The list of reserved network IDs is as follows:
 
@@ -120,21 +119,23 @@ The list of reserved network IDs is as follows:
 | Cjdns overlay network address
 |}
 
-To allow for future extensibility, clients MUST ignore address types that they do not know about.
-Client MAY store and gossip address formats that they do not know about. Further network ID numbers MUST be reserved in a new BIP document.
+Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.
 
-Clients SHOULD reject addresses that have a different length than specified in this table for a specific address ID, as these are meaningless.
+Clients SHOULD NOT gossip addresses from unknown networks because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.
+
+Further network ID numbers MUST be reserved in a new BIP document.
+
+Clients SHOULD reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.
 
 See the appendices for the address encodings to be used for the various networks.
 
-==Compatibility==
+==Signaling support and compatibility==
+
+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". Sending or not sending this message does not imply any preference with respect to receiving unrequested address messages.
 
-Send <code>addrv2</code> messages only, and exclusively, when the peer has a certain protocol version (or higher):
-<source lang="c++">
-//! gossiping using `addrv2` messages starts with this version
-static const int GOSSIP_ADDRV2_VERSION = 70016;
-</source>
-For older peers keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types.
+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.
 
 ==Reference implementation==
 
@@ -142,15 +143,13 @@ The reference implementation is available at (to be done)
 
 ==Acknowledgements==
 
-- Jonas Schnelli: change <code>services</code> field to VARINT, to make the message more compact in the likely case instead of always using 8 bytes.
-
-- Luke-Jr: change <code>time</code> field to VARINT, for post-2038 compatibility.
+- Jonas Schnelli: change <code>services</code> field to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize], to make the message more compact in the likely case instead of always using 8 bytes.
 
 - Gregory Maxwell: various suggestions regarding extensibility
 
 ==Appendix A: Tor v2 address encoding==
 
-The new message introduces a separate network ID for <code>TORV2</code>. 
+The new message introduces a separate network ID for <code>TORV2</code>.
 
 Clients MUST send Tor hidden service addresses with this network ID, with the 80-bit hidden service ID in the address field. This is the same as the representation in the legacy <code>addr</code> message, minus the 6 byte prefix of the OnionCat wrapping.
 
@@ -164,10 +163,11 @@ onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion"
  CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]
 
  where:
-   - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service.
-   - VERSION is an one byte version field (default value '\x03')
+   - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service
+   - VERSION is a one byte version field (default value '\x03')
    - ".onion checksum" is a constant string
    - CHECKSUM is truncated to two bytes before inserting it in onion_address
+   - H() is the SHA3-256 cryptographic hash function
 </pre>
 
 Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte PUBKEY part in the address field. As VERSION will always be '\x03' in the case of v3 addresses, this is enough to reconstruct the onion address.