The document discusses eclipse attacks on Bitcoin's peer-to-peer network, where an attacker can isolate a victim node by controlling its connections and allowing the attacker to double-spend with less than 51% of the network's mining power; it analyzes how many IP addresses an attacker would need using botnets or infrastructure to eclipse a node, and proposes several countermeasures that Bitcoin has implemented or could implement to make eclipse attacks more difficult.

1. Eclipse Attacks on Bitcoin’s
Peer-to-Peer Network
Ethan Heilman and Alison Kendler, Boston University; Aviv Zohar, The Hebrew University of
Jerusalem and MSR Israel; Sharon Goldberg, Boston University
24th USENIX Security Symposium
August 12–14, 2015 • Washington, D.C.
Summarized by Hideyuki Komaki (ID: husky)

2. Outline
1. Eclipse attacks & implications
- What is an eclipse attack?
- 51% attacks with far less than 51% of the mining power.
- N-Confirmation double spending
2. How to eclipse Bitcoin node
- P2P network details
- How to exploit it
3. How many IPs does the attacker need?
- Models & Experimental result
- Botnets & Infrastructure
4. Countermeasures
- Current deployment
- Effectiveness of countermeasures

3. What is an eclipse attack?
👿
👿
👿
👿
👿
👿
👿
👿
👿
👿
👿
👿
Max 8 outgoing TCP
connections by default
(purple)
Max 117 incoming TCP
connections by default
(blue)
< P2P gossip network >
Each node uses a randomized protocol
to select eight peers with which it forms
long-lived outgoing connections, and to
propagate and store addressed of other
potential peers in the network.
By manipulating the P2P network, the
attacker eclipse the node.

4. Implications of an eclipse attack
👿
1. 51% attack
2. N-Confirmation double spending
30% of mining power 30% of mining power40% of mining power
👿
30% of mining power
70% of mining powerMerchant

5. How to eclipse a node?
1. Fill node’s peer tables, with attacker IPs.
2. The node restarts and loses it current outgoing connections.
3. Node makes new connections to only Attacker IPs.
How to store network information & why does it have vulnerability?

6. Storing and Selecting IPs.
New Table
256 Buckets
Tried Table
64 buckets
New table: IPs the node heard about. (the node has yet initiated
a successful connection but learned from DNS seeder or ADDR
message.)
Tried table: IPs the node peerd with at some point. (an incoming
or an outgoing)
To find an IP to make an outgoing connection to:
1. Choose new or tried table to select from.
2. Select an IP (biased toward “fresher” timestanps).
3. Attempt an outgoing connection to that IP.

7. Storing and Selecting IPs.
New Table
256 Buckets
Tried Table
64 buckets
140.254.129.21
140.254
/16 IPv4 prefix
An IP address sent to
tried.Hash-by-group makes attack harder! But...

8. Storing and Selecting IPs.
New Table
256 Buckets
Tried Table
64 buckets
Why can an attacker fill node’s peer table with attacker IPs?:
Vulnerability 1: Selection Bias to choose outgoing node.
Vulnerability 2: Try-try again (An attacker can resend IPs.)
Vulnerability 3: Eviction Bias
Full bucket case:
1. Randomly select 4 IPs.
2. Delete oldest IP.
3. Insert new IP.

9. How many IPs does the attacker need?
~ Botnet case ~Approach:
1. Model Bitcoin with probability analysis & Monte-Carlo simulations.
2. Use these models to determine effective attack parameters.
3. Experimentally verify these parameters against Bitcoin nodes.
Bot
< Analysis of worst case for attacker >
Before attack: Tried table is 99.9% full of
honest IPs (4093 IPs).
Attacker Resources: Botnets of 4600 IPs, 2
IPs per group. 5 hours invested.
After attack: Node’s tried table is now 98.8%
attacker IPs.

10. How many IPs does the attacker need?
~ Infrastructure case ~
< Analysis of worst case for attacker >
Before attack: Tried table is 99.9% full of
honest IPs (4090 IPs).
Attacker Resources: Infrastructure of 8192
IPs, 32 group. 10 hours invested.
After attack: Node’s tried table is now 98%
attacker IPs.
the number of addresses per
group t.
Approach:
1. Model Bitcoin with probability analysis & Monte-Carlo simulations.
2. Use these models to determine effective attack parameters.
3. Experimentally verify these parameters against Bitcoin nodes.

11. Live experiment
Before attack:
Connected a node to the bitcoin network for +43 days.
Node’s tried table has 298 honest IPs.
Attacker Resources:
Botnets of 400 IPs = 400 groups, 1 IPs per group.
1 hour invested.
After attack:
Tried table still mostly empty but 57% of IPs are attacker IPs.
Experimental results:
84% attacker success rate (all 8 going connection eclipsed.)

12. Countermeasures
1. Deterministic Random eviction
- Vulnerability: The attacker can send IPs over and over again.
- Countermeasure: just as each address deterministically hashed to a single bucket in tried and
new, an address also deterministically hashed to a single slot in the bucket.
2. Random selection
- Vulnerability: The heavily bias makes attack easier.
- Countermeasure: eliminate the bias and select an address at random from tried and new bucket.
3. Test before evict.
- Vulnerability: An older address are likely to be evicted, so attacker IPs get into the bucket easier.
- Countermeasure: before evicting an older address, check if the address can connect successfully,
if so, the address won’t be evicted.
with test
before evict
without test before evict

13. Countermeasures
4. Feeler Connections
- Vulnerability: current bucket allow to insert “trash”.
- Countermeasure: Add an outgoing connection that establish short-lived test connections to
randomly-selected addresses in new. If connection success, the address is evicted from new and
inserted into tried; otherwise, the address is evicted from new.
5. Anchor connections
- Vulnerability: all outgoing connection will be refresh after the restart.
- Countermeasure: add an anchor table that stores current outgoing connections.
6 More buckets
- Countermeasure: increase the size of the tried and new tables. (it needs to combine other
countermeasure).
7 More outgoing connections
- Countermeasure: increase the number of outgoing connections.

14. Countermeasures
8. Ban unsolicited ADDR message
- Vulnerability: the attacker can fill new bucket with trash addresses easier.
- Countermeasures: A node could choose not to accept large unsolicited ADDR messages from
incoming peers, and only solicit ADDR messages from outgoing connections when its new table is
too empty. It prevents adversarial incoming connections from flooding a victim’s new table with
trash addresses.
9. Diversify incoming connections
- Vulnerability: Current bitcoin system allows incoming connections from the same IP address.
- Countermeasures: a node accept only a limited number of connection from the same IP address.
10. Anomaly detection
- Countermeasures: monitoring and anomaly detection system that look for the behavior that mining
power is gradually decreasing.

15. Deployment
Link of github: https://github.com/bitcoin/bitcoin/pull/5941