-
Notifications
You must be signed in to change notification settings - Fork 1
BIP nounsolicitedaddr
This document proposes a new P2P message to avoid relay of addresses to peers that don't make any use of them.
This BIP is licensed under the 2-clause BSD license.
The propagation of nodes' addresses in the Bitcoin network works in two ways:
1. A node may explicitly request another node to send it a bunch of addresses, using the getaddr message.
2. Nodes occasionally send unsolicited address messages to other nodes which in turn send them to other nodes.
The second point relies on the assumption that a node which receives unsolicited address message will further relay it to others, eventually, or at least do something useful with it (maybe add it to its own local address database). However, that is not true for some nodes which just ignore such messages (for example SPV nodes, or block-only connections of Bitcoin Core), acting as black holes and impeding address propagation. This BIP aims to address the problem by having those nodes announce themselves as such.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The nounsolicitedaddr message is defined as a message where
pchCommand == "nounsolicitedaddr".
It has no payload, is serialized in the standard encoding for P2P messages and
has the following meaning: the node that emitted it wishes to not receive
unsolicited address messages (either unsolicited
addr or
unsolicited
addrv2).
Nodes are RECOMMENDED to send nounsolicitedaddr to their peers if
they do not further relay addresses to other nodes and do not do anything useful
with the unsolicited address messages they receive.
This way they will improve address propagation network-wise and will reduce
incoming traffic to themselves.
Nodes that receive nounsolicitedaddr are RECOMMENDED to not send
unsolicited address messages to the nodes from which they received
nounsolicitedaddr.
The nounsolicitedaddr message can be sent at any time during the
communication. This would allow a node to "switch off" after some time or after
it has accumulated sufficient addresses.
Nodes that don't support nounsolicitedaddr SHOULD ignore it.
Nodes SHOULD NOT treat for misbehavior other nodes that have ignored their
nounsolicitedaddr message and send unsolicited address messages
nevertheless.
A node that receives nounsolicitedaddr followed by
getaddr is expected to still reply to getaddr like
usual. nounsolicitedaddr only relates to unsolicited address
messages.
?
sdaftuar:
- Would the proposed "no-unsolicited-addrs" message be deprecated in the future by in favor of a message that negotiated which types of network addresses (ipv4, ipv6, tor, i2p, ...) a peer is interested in specifically?
- To what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all?
- What fraction of the network should receive any given announced address, over some time period?