The PR branch HEAD was 0c194ff at the time of this review club meeting.
Notes
The Bitcoin network uses addr messages to communicate network addresses
(the locations of nodes). See the Bitcoin wiki p2p
documentation for
more details.
Good address propagation improves network connectivity and increases the
difficulty of executing an eclipse attack.
Bitcoin Core nodes will periodically self-announce (also known as
self-advertise) their own network address to peers.
When a Bitcoin Core node receives an addr message that contains 10
addresses or fewer, it forwards them to 1 or 2 peers, selected at random.
If we assume all nodes do this, then self-announcements should reach a large
portion of the nodes on the network.
However, we know that some nodes on the network do not relay addr messages
that they receive. Two known cases are block-relay-only connections from Bitcoin
Core nodes, and connections from certain light clients. We refer to these
connections as addr black holes. addr messages go in, but they never escape!
If a large portion of the connections on the network are addr black holes, then
addr propagation is impacted. Self-announcements won’t reach a majority of nodes
on the network. It’d be better if we could somehow avoid picking black holes as
the 1 or 2 peers that we select for relaying addr messages to.
This PR defers initialization of m_addr_known of inbound peers until the
peer sends an address related message (addr, addrv2, getaddr or
sendaddrv2). The node uses the presence of m_addr_known to decide whether
the peer is a candidate for relaying addr messages received from the
network.
What is an addr black hole? Why is this a concern for addr propagation?
How does Bitcoin Core implement self-announcements? How would you expect a
single advertisement to propagate throughout the network?
How does this PR propose to improve addr black holes? What are possible
issues an approach like this could have? What does this approach not
address?
What are the addr related p2p messages in the bitcoin protocol? What do
each of them mean? How does the logic to send and receive each message
change with this PR?
Could this change potentially be disruptive to other software on the
network? How so?
What are alternative approaches for achieving the intended goal?
<amiti> svav: indeed, the goal of good addr relay is to be robust to eclipse attacks, can you describe more about what part specifically this PR contributes to?
<glozow> i thought of black hole just in relation to our node (they wont forward addrs we send them) and not necessarily that they dont participate in addr relay at all
<lightlike> I'd say that it does reduce the occurrence of black holes, because we relay a given ADDR to a limited number of nodes, and those messages that aren't sent to black holes will be sent to other nodes instead.
<b10c> amiti: to rephrase RE propagation pattern: A self-announces to B, B only relays it to 1 or 2 peers as otherwise (compared to relay to e.g. all 50 peers) we'd flood the network with addr's, right?
<lightlike> ccdle12: block-relay-only is not a node property, it's a connection property, currently a node has only 2 outgoing block-relay only connections. you could think of it as an extra stealthy network within the network.
<amiti> How does this PR propose to improve addr black holes? What are possible issues an approach like this could have? What does this approach not address?
<amiti> How does this PR propose to improve addr black holes? What are possible issues an approach like this could have? What does this approach not address?
<oldgoat5> "How does this PR propose to improve addr black holes?" - this pr appears to add a SetupAddressRelay flag, which can be set to true for full nodes, and false for light clients. Â Currently some nodes are not likely to forward addresses (light clients), thus some announcements will be lost. Â This pr wants nodes to declare whether they will forward
<amiti> oldgoat5: mostly, but some clarifications: 1. there are other types of connections that won't forward addresses, eg. block-relay-only conn or potentially other software on the network
<lightlike> where did a typical light client that doesn't participate in addr relay but somehow managed to connect to us get our IP? From the DNS seeds?
<jnewbery> lightlike: good question! Maybe it connected to some hard-coded peers, sent a getaddr to get a diversity of peers and then connected to some of them (?)
<amiti> and that would suck, because this is the main technique for ongoing addr relay, so if a node doesn't hear about addrs, it would be more vulnerable to being eclipsed
<amiti> sugarjig: oh interesting. I don't think bitcoin core can run on an inbound-only method. I'd have to check that you can't do something weird with startup flags though
<amiti> one piece of feedback that has been given to me is that I should communicate about this on the bitcoin-dev mailing list & research the expectations of other software on the network
<amiti> we have 5 minutes left, which I don't think is enough to dig into question #5 or 7, so I'll open the floor to any remaining questions about addr relay
<glozow> i have a clarification question, if you're about to relay addrs and you have 0 candidates (e.g. no m_addr_known with any of your peers) for any of your non-source peers, do you also just not relay it?
<lightlike> this touches #7, but I'm really interested in it: have you considered the alternative approach treating addr messages to potential black holes as additional messages (but not stopping them) - e.g. relaying to one more peer if we suspect our peer is a black hole?
<amiti> on the other hand, that behavior might be exploitable because you're relying on the peer to indicate to you whether or not they are a black hole, and maybe that could lead to them receiving more addrs than otherwise?