The next edition of my Bitcoin Core contributing course will be on October 10th in Utrecht, right before the Bitcoin Amsterdam conference. Sign up here.
Today we continue chapter 8, covering an attack with fake nodes that took place in the summer of 2021.
A couple weeks after this attack, Matthias Grundmann and Max Baumstark wrote a paper describing the attack and speculating about the reasoning behind it.
What they’re guessing is that this attacker wasn’t so much trying to destroy the network, as they were trying to map the network to get a sense of how well nodes are connected to each other. And the reason they can do that is because when you receive 10 IP addresses, you’ll forward each of them to exactly two of your peers.
If the attacker also connects to you using a regular (not spamming) node, it’ll receive some fraction of the spam address that you forward. From that fraction, it can calculate how many peers you have. More generally, in a surveillance attack like this, it’s like they’re monitoring the echo of their own attack. By looking at this echo, they can determine a little bit of what the network looks like, including the shape of it, how well connected it is, how robust it is, etc. This information could potentially be used for future attacks, or it could just be for research purposes.
There are some existing defense mechanisms in nodes that make it more difficult to use this information. For example, if you’re telling a node a bunch of IP addresses, it’s not going to immediately connect to all of them — not only because that would make it too easy to invite a node into connecting to a trap, but also because, most of the time, a node already has sufficient connections. It also doesn’t relay all of them, and for those addresses that are relayed, there’s a random time delay. So, it makes it very difficult to say specifically which node connects to which node connects to which node.
These defense mechanisms are added to Bitcoin Core incrementally, often as a defense against eclipse attacks, as we explained in chapter @sec:eclipse. Essentially, when people do these types of attacks — probing the network in weird ways — experienced developers and security researchers will look at them and see how they can add something against them.
In this instance, they added a counter measure. Normally, when people are acting nice, they’ll connect to you and send you one IP address — namely their own. Occasionally, they’ll send you some other IP addresses, but not very frequently — the average node will share an IP address with a peer maybe once every 20 seconds.
Because an attacker will send addresses at a much higher rate, the counter measure is to introduce a rate limiter. This basically says, “OK, when a new node connects to me, I’ll allow it to send me one address immediately, and then I’ll allow up to one address every 20 seconds.” It tracks how many seconds have gone by, and if the node is sending too many addresses, it’ll ignore the new ones that go over the rate limit. So the “attackers” don’t get punished, but rather ignored.
Of course, there are cases where nodes actually want to receive lots of addresses from their peers. For example, if somebody connects to you and you say, “Please tell me addresses, and give me up to 1,000,” then of course the response won’t be rate limited. In such a scenario, you’ll make sure that they can actually give you those addresses, but if it’s unsolicited, then you rate limit it.