What is an Eclipse Attack? | Binance Academy

Introduction

An eclipse attack is a relatively simple attack that a malicious actor may deploy to interfere with nodes on a network. As the name may suggest, the attack aims to obscure a participant’s view of the peer-to-peer network, in order to cause general disruption, or to prepare for more sophisticated attacks.

Eclipse attacks may sound similar, on the surface, to Sybil attacks. While they share certain similarities – the malicious actor will flood the network with fake peers – their end goal is ultimately different. An eclipse attack takes aim at a single node (for reasons explained in a later section), whilst a Sybil attack is a network-wide attack designed to game the reputational system of the protocol.

The concept is discussed at length in the 2015 paper Eclipse Attacks on Bitcoin’s Peer-to-Peer Network, in which researchers from Boston University and Hebrew University report their findings from their experiments in mounting eclipse attacks, as well as possible countermeasures to combat them.

How an eclipse attack works

Bitcoin miners require specialized equipment in order to generate new blocks, but non-mining (or full) nodes are easily run on minimal computational power. This aids the decentralization of Bitcoin, as anyone can spin up a node on a low-spec device. The software maintains a database of transactions that it synchronizes with its immediate peers, so as to remain in lockstep with the network.

A limiting factor for many nodes is bandwidth. Though there is a tremendous amount of devices running the software, the average device is unable to connect directly to many of them due to limitations set out in the Bitcoin software (which only permits a maximum of 125 connections).

In an eclipse attack, the malicious actor will ensure that all of the target’s connections are made to attacker-controlled nodes. The entity will first flood the target with its own IP addresses, which the victim will likely connect to upon the restart of their software. A restart can either be forced (i.e. with a DDoS attack on the target), or the attacker can simply wait for it to occur.

Once this has occurred, the unsuspecting victim is at the mercy of the malicious nodes – with no view of the wider network, they can be fed incorrect data by the attacker.

Consequences of an eclipse attack

If an attacker is expending the resources to alienate a peer from the network, they probably have a motive to do so. There are a handful of successive attacks that can be more easily launched once a node has been suffocated.

0-confirmation double spends

If an individual accepts a transaction with no confirmations, they’re at risk of a double spend. The transaction may have been broadcast, but until it has been included in a block (and therefore committed to the blockchain), the sender can easily craft a new transaction that spends the same funds somewhere else. If the new transaction has a higher fee, a miner will likely include it before the original, invalidating the earlier one.

Some businesses and individuals accept these 0-confirmation transactions. Consider a merchant, Bob, who sells high-end vehicles. He is unaware that Alice has eclipsed his node, and suspects nothing as she places an order for a luxury sports car. She creates a transaction, which Bob then broadcasts to the network. Satisfied that the payment is on its way, he hands over the keys to the car and Alice speeds off.

Of course, the transaction wasn’t broadcast to the network – Bob has merely relayed it to Alice’s malicious nodes, which will not relay it to honest nodes. While this transaction hangs in limbo, Alice spends the same funds on the (real) network, whether to another party or to an address she owns. Even if the initial transaction to Bob is eventually seen, it will be rejected as the coins have already been spent.

N-confirmation double spends

The N-confirmation double spend is similar to the 0-confirmation one, but involves more preparation. Many businesses prefer to wait for a certain number of confirmations before marking a payment as valid. To route around this, the attacker must eclipse both miners, and the merchant. Once the attacker has set up the order with the merchant, they broadcast a transaction to the (eclipsed) miners. The transaction is confirmed and included in the blockchain – but this blockchain is not the chain that the majority of the network observe, since the miner is cut off.

From there, the attacker relays this version of the blockchain to the merchant, who releases the goods under the belief that the transaction has been confirmed. Once the eclipsed nodes rejoin the actual network, the blockchain they mistakenly believe to be valid is orphaned by the one that the rest of the network has been working on (this bears some similarities to a 51% attack).

Weakening competing miners

An eclipsed node will continue to operate, oblivious to the fact that they have been segregated from the network. Miners will continue to mine blocks within the rules laid out by the protocol, but the blocks added will be discarded as they sync with honest peers.

Theoretically, a large-scale eclipse attack on major miners could be used to facilitate a 51% attack. As it stands, the cost to take over the majority of Bitcoin’s hashing power is simply too high for even the most resourceful of attackers – at ~80TH/s, the entity would need more than 40TH/s to attempt such a maneuver.

In a hypothetical scenario where this hashing power is distributed between 10 parties (such that each owns 8TH/s), the attacker can significantly lower the requirements for a 51% attack by cutting these parties off from the network. If five are eclipsed, 40TH/s is removed from the race to find the next block, and the attacker now only needs to acquire slightly upwards of 20TH/s to take control.

Other sabotage that can be achieved by eclipsing targets includes the manipulation of nodes for selfish mining, or the engineering of races between miners to find the next block.

Mitigation

With enough IP addresses, an attacker can eclipse any node. The most straightforward method of preventing this from happening is for an operator to block incoming connections, and to only make outbound connections to specific nodes (such as those that have been whitelisted by other peers). As the research paper points out, however, this is not an approach that works at scale – if all participants adopt these measures, new nodes will not be able to join the network.

The authors propose a handful of tweaks to the Bitcoin software, some of which have been integrated since the paper’s release. These make eclipse attacks more costly through minor modifications to the code, such as random selection of new connections and greater capacity for storing addresses.

Closing Thoughts

Eclipse attacks are carried out at the peer-to-peer network level. Deployed as a standalone attack, they can be something of a nuisance. Their true effectiveness is in potentiating other attacks that impact targets financially, or provide the attacker with an advantage on the mining front.

In the wild, there has yet to be serious consequences resulting from an eclipse attack, but the threat still exists in spite of the countermeasures integrated into the network. As with most of the attack vectors that exist for Bitcoin and other cryptocurrencies, the strongest defense will be that which makes it financially prohibitive for malicious parties to attempt them.