Bitcoin Magazine
The Core Issue: Your Node Vs. The Digital Wilderness
Over 50 years after the first inter-networked message, peer-to-peer networks remain rare beasts in the jungle of the Internet. Bitcoin’s ability to provide an open monetary system depends on its peer-to-peer architecture, and across its attack surface it is the networking layer–how peers discover and connect to each other–that is the most vulnerable. There are two main places problems can occur: Bitcoin’s own peering protocol, and the Internet protocols that Bitcoin’s protocol depends on. In this light Core has a dual mandate to prevent Denial of Service (DOS) vectors that can be abused between nodes, and enable nodes to communicate safely in the wider adversarial environment that is the Internet.
P2P
“Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.”
– Satoshi, Nov 7, 2008 [1]
The P2P protocol encompasses how nodes exchange messages about transactions, blocks, and other peers. This exchange of information is required before any transaction or consensus validation can occur, and is therefore a primary concern.
There have been several bugs in this area over the years. In 2017, for example, a malicious SOCKS server vulnerability was patched and disclosed [2]. This “buffer overflow” vulnerability could theoretically lead to many different attacks: crash the node, inject malicious payloads, or modify data on the node. In 2020, a high severity vulnerability was reported and patched where a remote peer could get addresses banned, growing the banlist quadratically, and is therefore a DOS on the node [3]. The vulnerability was not disclosed until 2024. This bug is correctly marked as “high severity” since the attack is simple to execute, its effect results in a loss of function for the node, and it has few preconditions required to make it work. These are the kind of bugs that keep Core developers up at night, and why it is highly encouraged to update your node to a still maintained version (older versions of Core are not actively maintained/updated).
This distributed network we call Bitcoin remains relatively small: the clearnet node count hovers around 20k nodes, and even assuming a generous 100k TOR nodes, we still have a small, easily surveillable network. Recently, Daniela Brozzoni and naiyoma showed [4] that if a node runs with both clearnet and Tor, it is trivial to map a node’s IPv4 and Tor addresses. It is very likely that this is already done by intelligence agencies and chainalysis companies. It then becomes easy to notice which nodes publish which transactions first, deducing the transaction’s original IP, and therefore location. While this is not a bug per se, since the node does not crash or misbehave, it can be considered a vulnerability, since it presents a method for tying a given IP address to a transac
