From 42ee3f5c15de34dfbe9473807d44685fa1354e86 Mon Sep 17 00:00:00 2001 From: Vasil Dimov Date: Fri, 10 Apr 2020 09:46:48 +0200 Subject: BIP155: include changes from followup discussions * 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). --- bip-0155.mediawiki | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) (limited to 'bip-0155.mediawiki') diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 5914241..ba0c798 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -78,8 +78,8 @@ This means that the message contains a serialized std::vector of th One message can contain up to 1,000 addresses. Clients SHOULD reject messages with more addresses. -Field addr has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject -longer addresses. +Field addr 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,10 +120,13 @@ 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. -- cgit v1.2.3 From 350189ad489c99a426915b123502a8339ef8d1ba Mon Sep 17 00:00:00 2001 From: Vasil Dimov Date: Tue, 9 Jun 2020 09:36:26 +0200 Subject: BIP155: use a dedicated message for signalling 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. --- bip-0155.mediawiki | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) (limited to 'bip-0155.mediawiki') diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index ba0c798..1364a3f 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -130,14 +130,13 @@ Clients SHOULD reject messages that contain addresses that have a different leng See the appendices for the address encodings to be used for the various networks. -==Compatibility== - -Send addrv2 messages only, and exclusively, when the peer has a certain protocol version (or higher): - -//! gossiping using `addrv2` messages starts with this version -static const int GOSSIP_ADDRV2_VERSION = 70016; - -For older peers keep sending the legacy addr message, ignoring addresses with the newly introduced address types. +==Signaling support and compatibility== + +Introduce a new message type sendaddrv2. Sending such a message indicates that a node can understand and prefers to receive addrv2 messages instead of addr messages. I.e. "Send me addrv2". + +sendaddrv2 SHOULD be sent after receiving the verack message from the peer. + +For older peers, that did not emit sendaddrv2, keep sending the legacy addr message, ignoring addresses with the newly introduced address types. ==Reference implementation== -- cgit v1.2.3