https://en.bitcoin.it/w/index.php?action=history&feed=atom&title=Eclipse_attack 2026-09-13T10:25:28Z Revision history for this page on the wiki MediaWiki 1.43.9 https://en.bitcoin.it/w/index.php?title=Eclipse_attack&diff=71463&oldid=prev 2026-09-13T07:32:55Z

<p>Create Eclipse attack stub: Heilman 2015 / Erebus peer isolation; AddrMan, feelers, anchors, ASMap mitigations; not PoW</p> <p><b>New page</b></p><div>An &#039;&#039;&#039;eclipse attack&#039;&#039;&#039; isolates a Bitcoin node from honest peers so that the victim&#039;s view of the chain and the [[Mempool|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|network]] will never confirm. The attack targets the peer-to-peer overlay, not proof-of-work directly.<br /> <br /> 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&#039;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.<br /> <br /> Bitcoin Core stores gossiped addresses in AddrMan, split into a &quot;new&quot; table of untested addresses and a &quot;tried&quot; 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&#039;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&#039;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.<br /> <br /> 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 &lt;code&gt;anchors.dat&lt;/code&gt; 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&#039;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.<br /> <br /> == See also ==<br /> * [[ASMap]]<br /> * [[Network]]<br /> * [[Bitcoin Core]]<br /> * [[Erlay]]<br /> * [[Watchtower]]<br /> <br /> == External links ==<br /> * [https://eprint.iacr.org/2015/263.pdf Heilman et al., Eclipse Attacks on Bitcoin&#039;s Peer-to-Peer Network (2015)]<br /> * [https://www.usenix.org/system/files/sec21fall-tran.pdf Tran et al., routing-aware peering against Erebus]<br /> * [https://github.com/bitcoin/bitcoin/pull/17428 Bitcoin Core PR 17428: anchor connections]<br /> * [https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki BIP 324 (encrypted P2P transport)]<br /> <br /> [[Category:Technical]]</div>

NotATether