Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

p2p: Avoid forwarding ADDR messages to SPV nodes #17194

Open
wants to merge 1 commit into
base: master
from

Conversation

@naumenkogs
Copy link
Contributor

naumenkogs commented Oct 18, 2019

Background

The primary method of relaying node addresses across the network is daily self-announcement and forwarding self-announcements of other nodes.
To rate-limit those, we relay them only to 1 or 2 peers (depending on whether the address is reachable for us).
Unfortunately, in current implementation there is a chance of choosing SPV nodes, which, to the best of my knowledge, currently do not forward those announcements.

Discussion

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).
Until that’s getting resolved, I’m suggesting a tiny patch that prevent forwarding (they still can request and learn) these announcements to SPV nodes.

Analysis

To justify the change, I decided to measure how does this relay perform in different conditions (see my script).
I measured how many nodes know about the new address relayed through this protocol (omitting batching <10 rule) within 360 “waves” of relay (which is roughly 3 hours).

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".

non-forwarding SPV nodes 1% 5% 10%
All nodes knowing addr (before the change) 90% 7% 0.2%
All nodes knowing addr (after the change) 94% 90% 87%
Exotic nodes knowing addr (before the change) 100% 17% 0.7%
Exotic nodes knowing addr (after the change) 100% 100% 100%

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).

Questions

  1. Would we make SPVs more vulnerable to addrman injections? Like, would it be easier for an attacker to fill their addrmans with malicious sybil nodes? (I guess we are already vulnerable it assuming some capabilities of an attacker, but would it be noticeably worse? EthanHeilman)
  2. Does the same apply to the old pruned nodes? (achow101 I think you mentioned that older nodes would also be excluded here). Should we forward these announcements to them, if this makes them noticeably more vulnerable?

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.

P.S.

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.

P.P.S.

I guess the biggest inaccuracy in my little experiment is that in practice, those exotic semi-reachable nodes are well-interconnected, so once the address makes it to one of those — it should be relayed a bit better. Maybe, I will try to measure.
Anyway, this does not disregard the problem.

Improved the script to take exotic inter-connectivity into account and updated the measurements.

@EthanHeilman

This comment has been minimized.

Copy link
Contributor

EthanHeilman commented Oct 18, 2019

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.

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.

@fanquake fanquake requested a review from sdaftuar Oct 18, 2019
@practicalswift

This comment has been minimized.

Copy link
Member

practicalswift commented Oct 20, 2019

Concept ACK

Thanks for working on this!

@MarcoFalke

This comment has been minimized.

Copy link
Member

MarcoFalke commented Oct 22, 2019

It is good for SPV nodes to get addrs sent to them

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 getaddr or getaddrv2 p2p message to solicit addresses.

@sipa

This comment has been minimized.

Copy link
Member

sipa commented Oct 22, 2019

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.

@harding

This comment has been minimized.

Copy link
Member

harding commented Nov 3, 2019

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

@naumenkogs

This comment has been minimized.

Copy link
Contributor Author

naumenkogs commented Nov 5, 2019

So, it seems like most of us agree that we should allow light clients to request addrs, and we should not send them unsolicited addr messages assuming they forward them.

Just wanted to clarify, it is exactly what this PR does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.