The Bitcoin network is made up of the computers running the Bitcoin consensus protocol who can communicate with each other directly, or indirectly through other Bitcoin nodes. In traditional centralized payment networks like SWIFT or ACH, participants communicate only with others who are known and vetted by a trusted authority. Participants in the Bitcoin network, however, are anonymous and no one decides who can participate. This decentralization and permissionless makes Bitcoin robust against attacks that target a single trusted authority. Bitcoin nodes rely on their peer nodes to accurately relay information about the state of the network and each node must decide for themselves which peers to trust. Bitcoin nodes are therefore vulnerable to attacks that attempt to influence the set of peer nodes they connect to.

The Problem

Most Bitcoin nodes do not have enough bandwidth to communicate with more than a fraction of the roughly 10,000 Bitcoin nodes that advertise their availability to accept connections. Bitcoin nodes must instead select a subset of peer nodes to connect to. If a Bitcoin node only connects to peers controlled by an attacker, then it is said to have been “eclipsed” from the honest network. An important design consideration for Bitcoin’s peer-to-peer protocol is how to prevent these “eclipse attacks.” An eclipse attack attempts to prevent one or more Bitcoin nodes from talking with honest peers nodes, and instead only receive information from the attacker’s nodes.

For example, an eclipsed Bitcoin miner can be given delayed announcements about newly mined blocks. Instead of working to extend the new tip of the block chain, an eclipsed miner will waste resources by continuing to try and find a solution that extends the old tip of the chain. This will cost them money and because miners often operate with little marginal profit, could put them out of business entirely. If a number of miners are simultaneously partitioned (eg. 30% of the network), then they can be tricked into mining a minority fork – that is, extending a chain of blocks with less total mining power than the main block chain.

A minority fork produced by a set of eclipsed miners can be presented to an eclipsed merchant or exchange to cause them to accept a transaction that the attacker has double spent on the main chain. The victim will be led to believe they received bitcoin because they will see it confirmed in a block mined in the minority chain produced by the group of eclipsed miners. At the same time the attacker can spend the same bitcoin back to themself on the main chain. Only after the attack will the victim realize the bitcoin payment they received was invalid. Miners and payment receivers can only avoid being misled about the correct state of the Bitcoin blockchain by maintaining connections to peers that are part of the honest Bitcoin network and not controlled by an attacker.

An eclipsed node also leaks information about transactions and mined blocks that originate from their node because they must be sent through nodes controlled by the attacker. When a transaction is sent from the victim, the attacker will know with certainty that it originated with the victim because they also know all of the transactions they sent to the victim. An attacker can also choose to delay or drop transactions originating from their victim and prevent them from being confirmed by the network. Users of second layer protocols like the Bitcoin Lightning Network are particularly vulnerable to this attack because they must get transactions confirmed within a certain period of time to prevent a malicious channel partner from stealing funds by confirming an out-of-date channel state. Like a double spend attack, this would allow an attacker to reverse a Lightning payment made to a merchant or exchange.

A “majority” (aka 51%) attack on the entire Bitcoin network has a cost that scales with the hash rate difficulty of the network, but attacking nodes via the p2p protocol can be much less expensive to mount. The cost of this type of attack scales with the number of IP addresses that must be used to successfully launch the attack. Majority attacks are costly to maintain and hard to hide, while an attack that uses the p2p protocol can more easily be executed covertly. Nodes controlled by an attacker can behave honestly while they secretly infiltrate Bitcoin’s p2p network and wait until they have successfully eclipsed their targets before launching an attack.

Current Mitigation Techniques

The risk of eclipse attacks exists for any decentralized peer-to-peer network, from bot-nets to decentralized file sharing protocols like Bittorrent. The Bitcoin network has adapted and extended the best practices developed for protecting peer-to-peer networks with protocol heuristics and alternate connectivity options to mitigate the risk of eclipse attacks. 

Protocol Heuristics

Because potential new peer nodes are learned about from existing peers, which may include nodes controlled by an attacker, new peers should be selected in a way that make it costly to launch an eclipse attack. Heilman, et al, in their paper “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network” propose some specific techniques that are now used by Bitcoin’s p2p protocol to help thwart eclipse attacks. Bitcoin nodes keep two distinct tables of IP addresses: one for ‘New Nodes’ and one for ‘Tried Nodes’. When a node first learns about a new node from one of its peers, the new node is placed in the ‘New Nodes’ table. Nodes that have been successfully peered with at some point in the past are stored in the ‘Tried Nodes’ table. A node that needs to make a new outgoing connection should select an IP address from these tables in a way that makes it expensive for an attacker to gain control of all of it’s outgoing connections. Initially all nodes in both tables are assumed to be honest so an attacker must try to evict the IP addresses of honest nodes from these two tables and over time replace them with ones it controls. As peer nodes periodically go offline and are randomly replaced by new nodes, it is important that these tables contain IP addresses from as many honest nodes as possible.

One assumption is that it is cheaper and easier for an attacker to control new IP addresses that are contiguous and from the same IP address block. For this reason each table maps individual IP addresses to a limited set of buckets. Addresses from the same IP block are stored in the same bucket, and each bucket can have no more than 64 addresses. This raises the cost of an attack by forcing an attacker to acquire IP addresses from many independent sources to be able to occupy more buckets.

For example, IP addresses managed by the University Of Fukui in Japan all have addresses from the top level domain 133.7.0.0/16. Because any addresses managed by the same top level domain share the first two root IP numbers (eg. 133.7…), only 64 addresses from this domain would fill a single bucket in the ‘New Nodes’ and ‘Tried Nodes’ tables – even if the attacker controlled all 65536 possible IP addresses from this domain. Any additional addresses controlled by an attacker would just evict existing nodes they control in the same bucket.

When a node needs a new peer to replace an existing peer that goes offline, it randomly selects from one of these two tables, randomly selects a bucket from that table, and then selects a random IP address from the selected bucket. Only if a node from the ‘New Nodes’ table has been successfully connected to does it get promoted to the larger and more persistent ‘Tried Nodes’ table. A verified new IP address only evicts an existing address from its corresponding bucket in the ‘Tried Nodes’ table if the previous node at that position in the table is offline; this technique is called “test before evict”. This rule favors previously used IP addresses which are assumed to be more trustworthy than newly tried IP addresses and rate limits how fast an attacker can replace previously tried nodes with new ones they control.

Another powerful technique is to periodically make “feeler” connections to test IP addresses in the ‘New Nodes’ table and only promote valid nodes to the ‘Tried Nodes’ table if they connect to a valid bitcoin node. This helps to prevent the attacker from filling up the ‘New Nodes’ table with random IP addresses; the attacker must run a node at every IP address they propose to add to the ‘New Nodes’ table and be prepared to pay to relay data from each. Nodes in the ‘New Table’ that do not actually connect to a Bitcoin node when tested by the “feeler” connection are not promoted to the ‘Tried Nodes’ table. This also helps ensure that before an attack begins that the ‘Tried Nodes’ table is well populated with a good set of active honest nodes.

This system of filtering IP addresses ensures that an attacker can only slowly and probabilistically introduce new IP addresses into the ‘Tried Nodes’ table of their target. Because both the ‘New Nodes’ and ‘Tried Nodes’ tables are randomly selected from, an attacker will need to occupy both tables with running nodes to increase their chances of being selected to replace an offline peer. All of these measures increase the costs to an attacker by requiring them to acquire more IP addresses and by forcing them to operate these IP addresses for a longer period of time to succeed with an attack.

Multihoming

Nodes run by large miners or exchanges can choose to connect to the Bitcoin network from more than one IP address or ISP. This makes it harder for an attacker who does not know about their victims alternative addresses to target them. Unfortunately, this approach can be too expensive and complicated for smaller node operators or in places with fewer or more expensive telecommunication options. Bitcoin’s p2p network can also be accessed via alternative internet protocols that obscures a node’s IP address, such as the Tor network or a VPN. A node can also reserve peer connections for whitelisted nodes it trusts or as part of a public consortium such as the FIBRE relay network. Maintaining alternative connections to specific nodes is complementary with the heuristic approach of binning addresses into a limited set of buckets. Both measures decrease the odds that an attacker can control all of a node’s peer connections. However, physical multihoming depends on having more than one independent telecom option available and alternative transport layers like Tor can be blocked by a local ISP. Node operators might also be forced to operate with fewer connections to the Bitcoin network in places where the cost of bandwidth is high.

Satellite Broadcasts

Blockstream’s Blocksat project is an example of an approach for creating an alternative connection to the Bitcoin network which bypasses a node’s local ISP. An attacker with even full control of the victims local internet connections can not easily stop a node with a satellite receiver from learning about blocks and transactions from the honest network. Likewise, if satellite broadcasts are unavailable or controlled by an attacker, the node can still remain connected to honest nodes via its local wired internet connection. An attacker must control both connections to attempt an eclipse attack.

A satellite connection offers a powerful protection against attacks, but a broadcast only system like Blockstream’s Blocksat does not create an outgoing connection for nodes to send their own blocks or transactions. An attacker could still censor transactions or attempt to deanonymize transactions or blocks that originate from a node.

Conclusion

Protocol heuristics and alternative connections to the internet currently provide users of Bitcoin network strong protection from eclipse attacks. However, as more value begins to move through the network there will be strong economic motivations for attackers to attempt these attacks. We must also consider the possibility of attack from state-level actors with low cost access to tier-1 ISPs and large blocks of IP addresses. I will discuss some potential future mitigation techniques in part two of this article.