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 transaction.
How to prevent this effectively is currently an open question.
The Badlands of the Web
“We build our computers like we build our cities. Over time, without a plan, on top of ruins.” – Ellen Ullman [5]
Bitcoin runs on the Internet, and its ability to remain a distributed and decentralized system depends on the properties of the Internet itself. Unfortunately, the Internet’s architecture as we know it today remains woefully insecure, with known attacks employed routinely. Most of these attacks are conducted undetected until damage has been done, and this is not to mention the surveillance regimes that permeate the Internet today.
The most well known and practical vector of attack to be concerned with is called an eclipse attack, where a victim node’s peers are all malicious, and feed a specific view of the chain or network to the victim node. This class of attack is fundamental in distributed systems, if you control a node’s peers, you control its awareness of the network. Ethan Heilman and collaborators presented one of the first practical eclipse attacks on Bitcoin at USENIX 2015 [6], and in 2018, the Erebus attack paper described a “stealthy” eclipse attack via a malicious Autonomous System (AS) [7].
These attacks largely leverage weaknesses in the way the Internet’s networks communicate amongst themselves, such as ASs routing topology or via a protocol called the Border Gateway Protocol (BGP). While there are ongoing initiatives to secure the BGP protocol–BGPsec, RPKI–they both have limitations that are well understood, and leave the Internet’s stewards pining for stronger solutions. Until then, the Internet will remain the wild west.
A recent analysis by cedarctic at Chaincode Labs found that Bitcoin nodes are homed within just 4551 ASs, a fairly small subsection of the constituent networks that make up the Internet. They describe a set of attacks that can lead to eclipse attacks by compromising the upstream AS that nodes operate in [8]. The small distribution of nodes amongst ASs and the specific relationships among these ASs creates a unique attack vector. While there are remediations, it is unclear whether this attack vector was well understood beforehand by bitcoiners or their adversaries.
Any attack that relies on compromising one or several ASs requires resources, coordination, and skills to achieve. Although no successful attack of this type has been reported on a Bitcoin node, such attacks have been successfully mounted against miners [9], wallets [10], swap platforms [11], and bridges [12]. While we’re not going to fix the Internet, we can arm nodes with the tools to operate in this adversarial environment.
Network Armory
Below are some features and functionalities that Bitcoin Core has developed or integrated support for in order to arm users against network level attacks:
TOR (the Onion Router) is the oldest privacy-focused overlay network incorporated in Bitcoin Core. It creates hops between a random network of peers to obfuscate traffic.
v2transport [13] encrypts connections between peers, hiding the traffic from snoops and censors. The aim is to thwart passive network observers from snooping on the contents of your communications with other nodes.
I2P (the Invisible Internet Project [14]) is an optional feature of Core which enables an additional, private, encrypted layer to one’s connections. It is a Tor-like anonymity network which relies on peers to obfuscate traffic between clients and servers.
ASmap [15] is another optional feature of Core which implements a mitigation for the Erebus attack that the authors already outlined in the paper, and applies to all AS-based attacks. By making Bitcoin’s peering mechanism aware of the AS that peers are coming from to ensure diversity amongst peers, an eclipse becomes exponentially more difficult, as an attacker would have to compromise many ASs, which is highly unlikely and almost impossible without being detected. Bitcoin Core supports taking a map of IP networks to their AS (an AS-map) since Core 20.0, and the Kartograf project enables any user to generate such an ASmap easily.
Given that the Internet is likely to continue being vulnerable to many attacks, one of the things we can do is observe our peers’ behavior to attempt to detect malicious behavior. This is the impetus behind the peer-observer project by 0xb10c [16]. It provides a full eBPF tracepoint-based logging system (a way to observe the tiniest actions in a program running on an operating system) to observe a node’s activity, including peer behavior. It also gives you everything you need to build your own logging systems.
Bitcoin Must Be Robust
Securing the ability to connect to peers and exchange messages is a keystone component of what makes Bitcoin tick.
Bitcoin operates in a multi-dimensional adversarial environment, in which many of the threats are created by limitations of the internet’s architecture itself. If Bitcoin is to survive and thrive, its developers and users must learn to navigate these strange waters.
The price of open networks is eternal vigilance.
Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!
This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.
[0] https://web.mit.edu/gtmarx/www/connect.html
[1] https://satoshi.nakamotoinstitute.org/emails/cryptography/4/
[2] https://bitcoincore.org/en/2019/11/08/CVE-2017-18350/
[3] https://bitcoincore.org/en/2024/07/03/disclose-unbounded-banlist/
[4] https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/
[5] https://en.wikiquote.org/wiki/Ellen_Ullman
[6] https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-heilman.pdf
[7] https://ihchoi12.github.io/assets/tran2020stealthier.pdf
[8] https://delvingbitcoin.org/t/eclipsing-bitcoin-nodes-with-bgp-interception-attacks/1965
[9] https://www.theregister.com/2014/08/07/bgp_bitcoin_mining_heist/
[10] https://www.theverge.com/2018/4/24/17275982/myetherwallet-hack-bgp-dns-hijacking-stolen-ethereum
[11] https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600
[12] www.coinbase.com/blog/celer-bridge-incident-analysis
[13] https://bitcoinops.org/en/topics/v2-p2p-transport/
[14] https://geti2p.net/en/
[15] https://asmap.org
[16] https://peer.observer
[13] https://github.com/asmap/kartograf
This post The Core Issue: Your Node Vs. The Digital Wilderness first appeared on Bitcoin Magazine and is written by Julien Urraca, Fabian Jahr, 0xb10c and CedArctic.
