diff options
| author | Vasil Dimov <vd@FreeBSD.org> | 2020-04-10 09:46:48 +0200 |
|---|---|---|
| committer | Vasil Dimov <vd@FreeBSD.org> | 2020-07-16 20:37:20 +0200 |
| commit | 42ee3f5c15de34dfbe9473807d44685fa1354e86 (patch) | |
| tree | cf8fa8c05d88e1dfb0417e787430e60ece260729 /bip-0155.mediawiki | |
| parent | cb071df902eafb7054635201a8b12e76f42774ad (diff) | |
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).
Diffstat (limited to 'bip-0155.mediawiki')
| -rw-r--r-- | bip-0155.mediawiki | 13 |
1 files changed, 8 insertions, 5 deletions
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 <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,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. |