Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
p2p: Avoid forwarding ADDR messages to SPV nodes #17194
The primary method of relaying node addresses across the network is daily self-announcement and forwarding self-announcements of other nodes.
During the meeting we reached a soft consensus that address relay participation should not be coupled to SPV/full node definition, but rather have an explicit flag (e.g. service flag).
To justify the change, I decided to measure how does this relay perform in different conditions (see my script).
So, according to my measurements, it does not affect the case where the address is reachable to everyone and we relay to 2 (unless there are really a lot of SPVs).
Let’s see what if the address is reachable to 5% of the network (I guess pretty fair assumption for Onion addresses, for example). Let's call those "exotic".
If you don't believe it's that bad, please make your own simulation to validate mine :)
These numbers can also be used to motivate the high-level change (see discussion).
We can forward it to these two groups IN ADDITION to forwarding to (1 or 2) peers, if there is a belief that this is might affect their security. The bandwidth overhead would be obviously very low.
This experiment also means that we're very vulnerable to just black holes when relaying exotic addresses, but I will write about it in a separate issue.
It is good for SPV nodes to get addrs sent to them, but it doesn't benefit the network as much as sending addrs to a full node. Ensuring addrs go to 2 full node peers without excluding SPV nodes seems to capture the requirements well.
Do you mean unsolicited addrs? If so, I tend to disagree. That would make it harder to run a bandwidth efficient non-addr-relay node (e.g. an "SPV node"). I think that addr messages should only be gossiped to bip-155 nodes or network nodes (detectable via service bit). All other nodes should send a
I think it's a bit more nuanced than that.
In an ideal world, I think light clients would participate in local IP address management. Perhaps they wouldn't relay addresses themselves, but even if not, they should be learning from IP addresses that are gossiped around.
In reality it seems that none of them do, and obviously gossipping IP addresses to nodes that are just going to ignore them is pointless.
I wanted to note that one SPV client I'm aware of does (or at least did) use addr messages to find nodes. E.g., see this code:
However, that wallet also uses BIP37 bloom filters, so I don't know what their strategy will be going forward with regards to using the P2P protocol. Directly relevant to this PR, it looks like they don't accept unsolicited addr messages anyway---they only accept responses to a getaddr message: https://github.com/breadwallet/breadwallet-core/blob/494aa99ed61df24d13e45f6b335cda192c1b765c/bitcoin/BRPeer.c#L282