Eclipse attacks
Eclipse attacks occur when a node is isolated from all honest peers but remains connected to at least one malicious peer.
Without any connections to honest peers, the eclipsed node won’t receive the latest blocks on the most proof-of-work block chain. This gives the attacker an unlimited amount of time to generate blocks containing double spends, so even an attacker with a small minority of hash rate can trick the victim into accepting confirmed double spends.
The attacker will also control what transactions the victim’s node receives. This allows them to tell the node about transactions not generally available on the network in order to prompt the victim’s node into taking an action (e.g. the attacker sends a transaction closing an LN channel only to the eclipsed node).
Finally, the attacker can control what transactions the victim can send. This allows the attacker to prevent the victim from sending time-critical transactions such as LN penalty transactions. It also means that any transactions generated by the victim can be definitively identified as originating from the victim—a loss of privacy.
To prevent eclipse attacks, node operators are encouraged to run their nodes on multiple network interfaces and, when possible, to maintain connections to at least a few other nodes over secure networks (e.g. VPNs). Within the limits possible for nodes with only a single interface, Bitcoin Core developers work to ensure the node connects to a large and diverse set of peers to reduce the chance that every one of a node’s peers is the same sybil attacker.
Primary code and documentation
Optech newsletter and website mentions
2024
- Bitcoin Core #29850 limits the max number of IP addresses accepted from an individual DNS seed
- Improved reproducible ASMap creation process
2023
2021
- LND 0.14.0-beta includes additional eclipse attack protection by sharing block headers
- Proposed
disabletx
message to help allow more block-relay-only peers
2020
- 2020 year in review: fast eclipse attacks against LN nodes
- Bitcoin Core PR #19858 improves partition resistance to eclipse attacks
- Review Club chat about PR #19858 to make eclipse attacks more difficult
- Eclair #1545 adds multiple header sources to make eclipse attacks harder
- CVE-2018-17145 InvDoS attack could’ve been used to eclipse nodes
- Bitcoin Core #19670 reserves inbound slots for block-relay-only peers
- Time dilation attack: using eclipse attacks to steal money from LN nodes
- Bitcoin Core 0.20 released with asmap feature to improve eclipse resistance
- Presentation about attacking Bitcoin Core, including using eclipse attacks
- Review club discussion of Bitcoin Core #17428 anchor connections
- Bitcoin Core #16702 chooses peers based on ASN instead of IP address
2019
- 2019 year-in-review: erlay and other P2P improvements
- Discussion of eclipse attacks on LN nodes
- Preventing eclipse attacks using block-relay-only connections
- Differentiating peers based on ASN instead of address prefix
See also
Previous Topic:
Ecash
Next Topic:
Eltoo