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).
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
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
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.
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.
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.
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.