# Eclipse Attack

The aim of this article is try to answer the question of ***"What is the difficulty of successfully achieving an eclipse attack? What resources and skills would be required to achieve such an attack?"***

To come up with an answer, we are going to go through some basics on how Bitcoin P2P network is configured, explain what are Eclipse Attacks and later on, answering the question.

## Context
First of all, let's review some key ideas on the P2P Bitcoin network:
* Cryptographic authentication between peers is not used, and nodes are identified by their IP addresses.
* Each node uses a randomized protocol to select 8 peers with which it forms long-lived outgoing connections, and to propagate and store addresses of other potential peers in the network.
* Nodes with public IPs also accept up to 117 unsolicited incoming onnections from any IP address.
* Nodes exchange views of the state of the blockchain with their incoming and outgoing peers.

### Buckets
Similarly to how memory chunks are stored in caches, tables can be divided into buckets, each containing 64 slots. There are two main advantages of using bucketing systems for address storage:
* Checking the existence of an address in a table distributed in buckets is more efficient, as we do not have to go over the whole table, but rather the bucket maps to.
* A bucketing system prevents an adversary from polluting all the buckets with addresses from the same IP network range.

Bitcoin has two different set of buckets that store peer information: a set of **new buckets** and a set of **tried buckets**.


New buckets consist of addresses of newly available peers, whereas tried buckets store addresses of already-connected peers. When a node first connects to a peer, it adds the peer’s information, along with a timestamp, to the tried bucket. The connected peer passes known peer information to the node, and the node stores this in the new bucket.

When the node connects to the attacker’s device, it will send information about the malicious peers so that the node stores those addresses in the new bucket.

## Codebase
In the `addrman` file we can find the configuration for the address manager, the default constants and the rules for the bucket system.

Stochastic address manager
 *
 * Design goals:
 *  * Keep the address tables in-memory, and asynchronously dump the entire table to peers.dat.
 *  * Make sure no (localized) attacker can fill the entire table with his nodes/addresses.
 *
 * To that end:
 *  * Addresses are organized into buckets that can each store up to 64 entries.
 *    * Addresses to which our node has not successfully connected go into 1024 "new" buckets.
 *      * Based on the address range (/16 for IPv4) of the source of information, or if an asmap is provided,
 *        the AS it belongs to (for IPv4/IPv6), 64 buckets are selected at random.
 *      * The actual bucket is chosen from one of these, based on the range in which the address itself is located.
 *      * The position in the bucket is chosen based on the full address.
 *      * One single address can occur in up to 8 different buckets to increase selection chances for addresses that
 *        are seen frequently. The chance for increasing this multiplicity decreases exponentially.
 *      * When adding a new address to an occupied position of a bucket, it will not replace the existing entry
 *        unless that address is also stored in another bucket or it doesn't meet one of several quality criteria
 *        (see IsTerrible for exact criteria).
 *    * Addresses of nodes that are known to be accessible go into 256 "tried" buckets.
 *      * Each address range selects at random 8 of these buckets.
 *      * The actual bucket is chosen from one of these, based on the full address.
 *      * When adding a new good address to an occupied position of a bucket, a FEELER connection to the
 *        old address is attempted. The old entry is only replaced and moved back to the "new" buckets if this
 *        attempt was unsuccessful.
 *    * Bucket selection is based on cryptographic hashing, using a randomly-generated 256-bit key, which should not
 *      be observable by adversaries.
 *    * Several indexes are kept for high performance. Setting m_consistency_check_ratio with the -checkaddrman
 *      configuration option will introduce (expensive) consistency checks for the entire data structure.


## What are Eclipse Attacks

The Eclipse attack allows an adversary controlling a sufficient number of IP addresses to monopolize all connections to and from a victim bitcoin node. The attacker can then exploit the victim for attacks on bitcoin’s mining and consensus system, including N-confirmation double spending, selfish mining, and adversarial forks in the blockchain.

Since the eclipse attack is performed on the network layer, it can break the security of the consensus layer too. Any attack on the consensus layer can be more effective when the node’s peer-to-peer protocol is compromised. A 51 percent attack without the attacker owning the majority of the computing power, or the double-spend attack even after several block confirmations, can both be performed when an eclipse attack is performed.

The attacker has to exploit a few vulnerabilities to replace legitimate peer addresses with their own addresses. Some of the vulnerabilities in Bitcoin nodes that can be exploited are as follows:

The node selects the IP addresses from the tried bucket with recent time stamps, which increases the probability of the attacker getting selected even if the attacker owns a small portion of the tried bucket addresses. The attacker can increase the chances by increasing the attack time.
Whenever an address bucket is filled, one of the addresses is removed randomly. Since the removed address is random, if an attacker’s IP is removed from the bucket, it can be eventually inserted by repeatedly sending it to the node.

### Populating Tried and New
Our attacker populates the tried table with addresses for its attack nodes, and overwrites addresses in the new table with “trash” IP addresses that are not part of the bitcoin network.

We fill new with “trash” because, unlike attacker addresses, “trash” is not
a scarce resource. The attack continues until the victim node restarts and chooses new outgoing connections from the tried and new tables in its persistant storage. With high probability, the victim establishes all eight outgoing connections to attacker addresses; all eight addresses will be from tried, since the victim cannot connect to the “trash” in new. Finally, the attacker occupies the victim’s remaining 117 incoming connections.

### Restart
The attack requires the victim to restart so it can connect to adversarial addresses. There are several reasons why a bitcoin node could restart: including
* ISP outages,
* power failures,
* software upgrades,
* failures or attacks on the host OS;

**Predictable restarts:**
* A node with a public IP has a 25% chance of going offline after 10 hours.
* Another predictable reason to restart is a software update

### Selecting Outgoing Connections
Upon restart, the victim makes all its outgoing connections to attacker addresses. To do this, we exploit the bias towards selecting addresses with fresh timestamps from tried; by investing extra time into the attack, our attacker ensures its addresses are fresh, while all legitimate addresses become increasingly stale.

**--> Solved:** check counter measure on Release notes
https://hub.packtpub.com/what-can-blockchain-developers-learn-from-eclipse-attacks-in-a-bitcoin-network-koshik-raj/

https://medium.com/witnet/the-p2p-bucketing-system-in-witnet-d893dce4b8c5

### Types of Attack

Group: is the /16 IPv4 prefix containing the peer’s IP address.
Every IP address maps to a single bucket in tried, and each group maps to up to four buckets

**Botnet attack**: The attacker holds several IP addresses, each in a distinct group. This models attacks by a botnet of hosts scattered in diverse IP address blocks. Many botnets have enough IP address diversity for this attack.

Botnet attack is far superior to the infrastructure attack. Filling f = 98% of the victim’s tried table requires a 4600 node botnet (attacking for a sufficient number of rounds).

**Infrastructure attack**: The attacker controls several IP address blocks, and can intercept bitcoin traffic sent to any IP address in the block, i.e., the attacker holds multiple sets of addresses in the same group.
This models a company or nation-state that seeks to undermine bitcoin by attacking its network.

An infrastructure attacker needs 16,000 addresses, consisting of s = 63 groups with t = 256 addresses per group. However, if our attacker increases the time invested in the attack τ, it can be far less aggressive about filling tried

## Success of the attact
The success of our attack depends heavily on τ , the time invested in the attack, and f , the fraction of attacker addresses in the victim’s tried table.

To prevent others from connecting to the victim, these TCP connections could be maintained for 30 days, at which point the victim’s address **is terrible** and forgotten by the network.


## Counter Measures on the Codebase
Release Notes 0.10.1

Release Notes 0.21.0

*Note: images are not mine and text is collected and digested from different articles.*