Eclipse Attacks in Bitcoin

Recently, Heilman et al. showed how to attack the Bitcoin mining protocol by monopolizing the connections of nodes in the system [2]. For example, the attacker could possess a large number of IP addresses at his or her disposal and controls a large number of machines (e.g., a botnet). Alternatively, the adversary might be an Internet service provider (ISP) or a nation state adversary. On the other hand, the victim node is assumed to have a public IP address; that is, the victim is not located behind network address translators (NATs). Finally, the attack requires the ability of the adversary to cause a restart of the victim’s Bitcoin client (e.g., by means of distributed denial-of-service attacks or when the victim upgrades his or her Bitcoin client).

The intuition behind eclipse attacks is straightforward. Eclipsing entails blinding the view of the victim from the blockchain and requires that the adversary is able to isolate the victim from the rest of the network by monopolizing all of the victim’s outgoing and incoming connections.

In [2], this is achieved by exploiting the way in which Bitcoin clients store the IP addresses that are advertised in the network. Namely, in Bitcoin, peers exchange addr messages that contain IP addresses and their time stamps. These messages are used by nodes to obtain network information from peers. Public IPs are stored at each node in two tables: tried and new tables. The tried table consists of 64 buckets; each can store 64 unique addresses from peers with whom the node has established communication before. The node also keeps the time stamps of each tried IP address.

When the node connects to a new peer, his or her address and the time stamp are added to the tried bucket. If the bucket is full, the new address is inserted at a random location in the bucket and replaces the address that was stored there. Similarly, the new table contains 256 buckets, each containing up to 64 addresses.

Since each Bitcoin node can have up to eight outgoing connections, and 117 incoming connections, the node selects the IP addresses to connect to from tried with probability p. Otherwise, the node selects with probability 1 - p the address to connect to from the new table; note that node selection is biased to IP addresses that have a recent time stamp. Therefore, for the adversary to monopolize the connections of his victim, the adversary has to populate the tried table with addresses that are under their control. Heilman et al. suggest populating the new table with bogus IP addresses (e.g., nonexisting IP addresses). Later on, when the victim restarts, then it will attempt to connect with addresses from the tried and new tables; all of the addresses that the victim will connect to are guaranteed then to be under the control of the adversary. Real experiments in the Bitcoin network show that eclipse attacks succeed with a probability of 84%.