Bitcoin eclipse attacks

The most studied form of the attack exploits a node restart. An adversary floods the victim's address manager with addresses it controls, then waits for the victim to restart — through a software upgrade, a power loss, or any other cause. On restart the node discards its live connections and selects new peers from its address store, and if the store has been saturated with adversarial addresses, the new connections are likely to be adversarial too. The research paper that named the attack, by Heilman, Kendler, Zohar and Goldberg, described this mechanism and proposed a set of countermeasures.

The reason the restart matters is that a running node has already established connections to peers it chose, and those connections are not easily displaced. A restart throws that away. This is why several of the deployed mitigations are specifically about what survives a restart.

Bitcoin Core's address manager divides the address space into buckets and groups, so that an attacker must control addresses spread across many network groups rather than many addresses in one group. Addresses are selected at random from the new and tried tables rather than by recency, which removes the bias the original attack relied on. Test-before-evict checks whether an address about to be displaced is still reachable before displacing it, and feeler connections periodically test addresses so that the tried table stays populated with addresses that are actually online. Together these raise the number of addresses an attacker must control to occupy a useful share of the victim's address store.

Two further measures address the restart case directly. Block-relay-only connections, introduced in Bitcoin Core 0.19, are outbound connections that relay blocks but do not participate in transaction or address relay; a node opens two of them by default. Anchor connections, introduced in 0.21, persist a small number of these block-relay-only peers across restarts, so a restarted node reconnects to peers it already trusted rather than selecting entirely from its address store. The choice to scope anchors to block-relay-only connections is deliberate: those connections leak less information about the node's activity than full-relay connections would.

These are deployed mitigations, not a proof of immunity. The research literature lists further countermeasures that are only partially deployed or still under discussion, including additional outbound connections, restrictions on unsolicited address messages, and anomaly detection for the traffic patterns an eclipse attempt produces. A reader should treat the deployed set as raising the cost of the attack rather than eliminating it, and should treat the undeployed set as proposals rather than features.