Eclipse Attack

Anna is accepting a bitcoin payment and watching her own node: a computer running software that participates in the Bitcoin network. It reports active connections, but an adversary controls all its important paths out. Messages still arrive, but only those the adversary allows her to see. That is the essence of an Eclipse Attack. One malicious connection usually is not enough: a working path to an honest node can deliver withheld blocks and disrupt the attacker’s control. A block groups transactions into a batch added to the shared history. [1] [6]

Ethan Heilman, Alison Kendler, Aviv Zohar and Sharon Goldberg described attacks on the Bitcoin network of the time in 2015. They studied how to fill a node’s address tables with attacker-controlled addresses so that, upon reconnection, it would connect only to the attacker’s computers. They exploited connection selection without breaking the mathematical methods that protect features such as digital signatures. The study also proposed defences; its historical results do not measure success against today’s version of Bitcoin Core. [1] [7]

Once isolation is achieved, the attacker can choose which blocks and transactions Anna receives and which are withheld. It can also prevent her own transactions from spreading or observe their origin. Capturing the connections alone does not require a majority of mining power. That does not mean every follow-on attack comes for free: producing new blocks, for example, requires real work. [1] [6]

Anna’s Full Node still checks signatures, spending conditions and the allowed miner reward. Signing here means using a private key, a secret numerical value, to create verifiable proof of authorization for a payment. Others can check the signature without knowing that secret. Anna’s node will not accept an invalid transaction merely because the only available source sent it. Yet validation cannot reveal a valid block that never arrived. You can similarly establish that a delivered letter is genuine without knowing that someone withheld all newer letters. Validity and completeness of available information are separate questions. [5] [9]

The node can remain at its last known block while others advance. An isolated miner may even keep mining an abandoned branch and lose an expected reward. A long wait for a block is not itself evidence of an attack, though: mining is random, and an ordinary outage can also cause problems. A combination of symptoms matters, not a slowly updating screen alone. [1] [5] [8]

An attacker can show Anna a valid private branch containing her payment while spending the same funds differently on the wider network. After connectivity returns, her node may switch to a valid branch with more accumulated work: a Reorg, or replacement of part of the accepted history. The payment on the abandoned branch may no longer be confirmed. But the attacker must supply Proof of Work for its blocks. This is the verifiable result of a computationally costly search. These blocks need that result too. The necessary work can also come from miners the attacker has isolated. An invented confirmation count cannot fool a Full Node; success also depends on the duration of isolation and the attacker’s resources. [1] [5] [6]

Defences try to stop every connection from ending up with the same adversary. Bitcoin Core groups known addresses and encourages network diversity when selecting outbound peers. An IP address identifies a network location for the program to connect to. Different IP addresses can still belong to one operator or pass through the same infrastructure. These measures reduce concentration and make attacks harder, but they do not prove that every peer is independent. [3] [4]

Bitcoin Core uses short feeler connections to check whether another address is reachable. Extra block-relay connections have a different role: they can bring new block headers — compact technical records of the blocks — and another view of how the chain continues. It is therefore inaccurate to say that every feeler immediately downloads the current history. The referenced Bitcoin Core 29.0 code shows these distinct defences; none alone guarantees an end to isolation. [4] [8]

A known peer added manually can provide another path if it is available and genuinely connected to the wider network. Several connections through one provider need not be independent, however. Using maintained software and understanding connection settings make more sense than blindly importing someone else’s address list. Your own validation remains in place: trusting a source’s availability does not give it permission to send invalid blocks. [2] [4] [6]

A Sybil Attack means one adversary operates under many identities; this can help an Eclipse Attack. Eclipse describes successful isolation of a particular node or selected group from honest sources. A broader network partition instead separates whole parts of the network and need not arise this way. For an ordinary user, the important point is that a Full Node provides independent validation, but also needs access to information outside the attacker’s control. [1] [6]