highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-06-29 02:00:54 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #907 from vasild/bip155_clarifications

Browse Source 
BIP155: include changes from followup discussions
This commit is contained in:
Luke Dashjr
2020-09-23 12:49:25 +00:00
committed by GitHub
parent 68bb026c56 350189ad48
commit 60bfc4bb53
1 changed files with 14 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
bip-0155.mediawiki
View File

@ -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. 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 Field <code>addr</code> has a variable length, with a maximum of 512 bytes (4096 bits).
longer addresses. Clients SHOULD reject messages with longer addresses, irrespective of the network ID.
The list of reserved network IDs is as follows: The list of reserved network IDs is as follows:
@ -120,21 +120,23 @@ The list of reserved network IDs is as follows:
| Cjdns overlay network address | Cjdns overlay network address
|} |}
To allow for future extensibility, clients MUST ignore address types that they do not know about. 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.
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 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. See the appendices for the address encodings to be used for the various networks.
==Compatibility== ==Signaling support and compatibility==
Send <code>addrv2</code> messages only, and exclusively, when the peer has a certain protocol version (or higher): 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".
<source lang="c++">
//! gossiping using `addrv2` messages starts with this version <code>sendaddrv2</code> SHOULD be sent after receiving the <code>verack</code> message from the peer.
static const int GOSSIP_ADDRV2_VERSION = 70016;
</source> 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.
For older peers keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types.
==Reference implementation== ==Reference implementation==