Eclipse attack
An eclipse attack isolates a Bitcoin node from honest peers so that the victim's view of the chain and the mempool is supplied only by the attacker. The victim can then be fed a minority fork, starved of blocks, or shown transactions that the rest of the network will never confirm. The attack targets the peer-to-peer overlay, not proof-of-work directly.
A Bitcoin Core node makes a small number of automatic outbound connections and accepts a larger number of inbounds. Consensus follows the chain of most accumulated work among the headers the node actually receives. If every peer is attacker-controlled, the node cannot hear about a heavier honest chain. Heilman, Kendler, Zohar, and Goldberg described a practical eclipse against then-current Bitcoin Core in a 2015 USENIX paper: filling the address manager with attacker addresses, then inducing a restart, caused the victim to reconnect only to the attacker with high probability, using a modest number of distinct IP groups or botnet hosts. Later work (the Erebus attack, Tran et al., 2020) showed that a network-layer adversary sitting on the victim's BGP path can occupy AddrMan groups with legitimately announced addresses and does not need to hijack prefixes. Eclipse is therefore both a peer-table problem and a routing-diversity problem.
Bitcoin Core stores gossiped addresses in AddrMan, split into a "new" table of untested addresses and a "tried" table of addresses that have recently accepted a connection. Outbound peers are selected from these tables with grouping so that many addresses in one /16 (or, with ASMap, one ASN) compete for the same slots. An eclipse proceeds by gossiping enough attacker addresses to crowd honest ones out of new and, after successful connections, tried; occupying the victim's inbound slots so honest peers cannot connect in; and waiting for, or causing, a restart so that on reboot the node dials outbound peers from the poisoned tables. Once isolated, the attacker can withhold blocks, delay them (time-dilation, which matters for Lightning timelocks and Watchtower monitoring), or present a private fork on which the victim's payments appear confirmed. The attacker does not need a majority of hash power against the victim — the victim simply never sees the honest work.
Countermeasures in Bitcoin Core include test-before-evict (an address is not inserted into tried until an existing tried address in that group is checked); feeler connections (short-lived outbound probes that test whether an address in new is actually a Bitcoin node, then promote it to tried — introduced after the 2015 paper, Bitcoin Core 0.13 era); more outbound slots and block-relay-only outbound connections that do not gossip transactions; anchor connections (Bitcoin Core 0.21), which write the two block-relay-only peers to anchors.dat at shutdown and reconnect to them first on the next start; ASMap grouping by ASN rather than /16; and optional connections over Tor, I2P, and other networks advertised via Addr v2, so that a single clearnet AS is not the only path. Related relay work such as Erlay improves transaction-inventory efficiency but is separate from eclipse defenses. No combination of these makes eclipse impossible for an adversary who controls the victim's only network path; they raise the number of independent addresses, groups, and restarts required. Light clients that connect to a handful of chosen servers have a simpler eclipse surface: those servers.