Pith. sign in

REVIEW 2 major objections 4 minor 2 cited by

Eclipsing Ethereum Peers with False Friends

T0 review · 2 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that a two-IP adversary can eclipse Go Ethereum nodes by placing one false friend in each discovery bucket and precomputing close node IDs, filtering the victim's view of the blockchain.

desk verdict A real, low-resource eclipse attack on Geth with a novel one-Sybil-per-bucket mechanism; the no-restart timeline is thinner than the headline claims but the core attack and math hold up. read the letter →

arxiv 1908.10141 v1 pith:D57MFQV4 submitted 2019-08-27 cs.CR cs.NI

Sebastian Henningsen , Daniel Teunis , Martin Florian , Björn Scheuermann This is my paper · ORCID
classification cs.CRcs.NI
keywords eclipseattackEthereumGethpeerdiscoveryKademliaSybillookup-bufferblockchainnetworksecurity
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper aims to show that Go Ethereum's peer-to-peer network can be eclipsed by a low-resource adversary even after the Geth v1.8.0 hardening, and that the weakness is not an implementation bug but a property of how Geth selects peers from its Kademlia-inspired discovery table. The proposed false friends attack needs only two IP addresses in different /24 subnets: one Sybil node per discovery bucket plus a large batch of precomputed node IDs lets the attacker control both mechanisms that fill Geth's eight outbound connection slots, while inbound slots are filled without restrictions. A sympathetic reader should care because a successful eclipse lets the attacker filter the victim's view of the blockchain, enabling follow-up attacks such as double spending, and because the attack works against long-running nodes without requiring a restart.

What carries the argument

The central object is Geth's peer-selection pipeline from its Kademlia-inspired discovery table to DEVp2p connection management. The table is divided into 17 buckets by log-distance (common prefix length), each bucket holds up to 16 nodes sorted by recent activity, and the /24 subnet restrictions allow two addresses per bucket and ten per table; the attack's leverage is that one active Sybil per bucket therefore dominates ReadRandomNodes, while the lookup-buffer, filled by XOR-distance lookups that retain the 16 closest nodes, can be dominated by always being queried and returning precomputed minimum IDs.

What would settle it

Measure connection durations on a set of unmodified long-running Geth v1.8.x nodes on the Ethereum mainnet for several weeks; if the 95th percentile of connections lasting over 60 seconds is not below about 5.5 days, or if a no-restart eclipse cannot be reproduced within roughly 4.8 days, the paper's 'matter of days' claim is undermined.

Watch

Extended reading notes

Core claim

On Geth v1.8.x, the attack succeeds by exploiting two interfaces between discv4 and DEVp2p. ReadRandomNodes returns only the heads of randomly chosen buckets, and buckets are sorted by recent activity, so an attacker who keeps one Sybil per bucket alive with regular pings ensures those Sybils are the nodes proposed for outbound connections. The lookup-buffer is populated by an iterative Kademlia-style lookup to a random target; with one Sybil per bucket the attacker is always among the queried nodes, and with roughly five million precomputed ECDSA-derived node IDs the attacker can almost certainly answer with IDs closer to the random target than any honest node's answer, filling the buffer with attacker nodes. Combined with unrestricted inbound connections, this lets two IP addresses from distinct /24 subnets eclipse a victim without a restart, because the paper's 18.76-day trace shows peer connections churn quickly (95% of connections over 60 seconds end within 5.5 days), so a long-running victim's honest connections drop on their own within days.

Load-bearing premise

The no-restart variant of the attack rests on the empirical claim, from a single 18.76-day trace, that 95% of peer connections lasting over 60 seconds end within 5.5 days; if real-world connection churn is lower, eclipsing a long-running node takes much longer than the reported days.

Editorial extensions

If this is right

  • An adversary with two IPs in distinct /24 subnets can fully control a Geth v1.8.x victim's peer slots within about an hour for a freshly restarted victim and within about 4.8 days for a long-running one, filtering the victim's view of the chain.
  • The attack does not require flooding the discovery table; a single Sybil per bucket is enough, directly bypassing the v1.8.0 countermeasures designed to make table flooding expensive.
  • The same precomputed set of node IDs can be reused across victims, since lookups target random IDs independent of the victim, making the attack cheap to repeat.
  • Geth v1.9.0's countermeasures, raising the peer limit to 50, selecting ReadRandomNodes uniformly from all table nodes, and throttling inbound connections, reduce but do not eliminate the vulnerability; the lookup-buffer remains poisonable and ID-based peer selection remains the root cause.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper stops short of testing other clients or DHTs; a natural extension is that any Kademlia-derived overlay with publicly derived buckets, cheap IDs, and bucket-head or closest-to-target peer selection is exposed to the same one-Sybil-per-bucket and precomputed-minimum-ID strategy.
  • Because the paper shows churn itself is what enables the no-restart eclipse, raising TCP and UDP timeouts or making connections sticky would be a direct defense; this is hinted at but not evaluated in the paper.
  • The residual lookup-buffer poisoning suggests that if Geth later reuses the buffer for outbound selection, or if the uniform-random fix is reverted, the false friends attack could return with only the buffer component; this is our inference from the paper's 'Unchanged: the lookup-buffer' section.
  • A quantitative comparison of attack cost against Geth v1.9.0 settings, such as how many IPs and precomputed IDs are needed now, would tell whether the implemented countermeasures truly move the required attacker resources out of the low-cost regime; the paper does not provide that number.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 4 minor

Summary. The paper presents the "false friends" eclipse attack against the Go Ethereum (Geth) client, targeting version 1.8.x. The attack places one Sybil node in each of the victim's discovery-table buckets and pre-computes a large number of node IDs so that adversarial nodes are preferentially returned both by ReadRandomNodes and by the lookups that populate the lookup-buffer. The authors derive the expected costs of bucket entry, the probability of receiving a FindNode request, and the probability of returning the smallest node ID; they then evaluate the attack on a live Ethereum node, including 50 trials against restarted victims and a single no-restart attack completed in 4.765 days. They also document countermeasures that were incorporated into Geth v1.9.0 after responsible disclosure.

Significance. If the claims hold, the paper shows that the security enhancements introduced in Geth v1.8.0 can be circumvented with only two IP addresses in distinct /24 subnets, and that even long-running nodes may be eclipseable without a restart. The strongest aspects are the code-grounded analysis of Geth's discovery logic, the live-mainnet validation, and the responsible disclosure that resulted in deployed countermeasures. The probabilistic derivations for bucket entry and for the single-minimum order statistic are standard and mostly correct. The main risk is empirical: the no-restart timeline rests on one connection-duration trace and one successful no-restart attack, and the lookup-buffer analysis covers only the minimum node ID rather than the full set of adversarial IDs required to control the buffer.

major comments (2)
  1. [Section VI-C and the no-restart experiment] The no-restart attack is the paper's main differentiator from [6], but the supporting evidence is a single 18.76-day connection-duration trace and one successful 4.765-day no-restart attack. The trace does not separate inbound from outbound connections. Since Geth accepts arbitrary inbound connections and the attacker can fill inbound slots at will, the aggregate churn distribution in Figure 8 may be dominated by short inbound connections and need not reflect the turnover of the 8 outbound slots that the eclipse actually requires. The reported 95% quantile of 5.5 days is therefore not established for outbound connections specifically. Two subsequent trials left one benign connection after 4.875 and 9.5 days, i.e., they did not reach full eclipse. Please provide direction-specific duration statistics or repeated no-restart trials before claiming that long-running remote nodes are eclipsed in a matter of days.
  2. [Section V-B2, Eqs. (8)-(12)] The derivation of the FindNode-request probability uses the 17th order statistic as the cutoff, but Geth always selects the 16 closest known peers for a lookup. For an attacker to be included among the 16 queried peers, its distance must be smaller than the 16th closest honest ID, Y_(16), not Y_(17). If Y_(16) < Z < Y_(17), there are 16 honest nodes closer than Z and Z is not queried. Equations (10)-(12) and Figure 4 should use l=16, the current bucket size k, rather than l=17, and the numerical values should be recomputed accordingly.
minor comments (4)
  1. [Section VI-C] The text states that the longest connection duration was 60 days while the trace itself lasted only 18.76 days; please clarify how durations are computed for connections that straddle the start or end of the measurement window.
  2. [Section VII-A and VI-C] Minor wording errors: 'the ones that where implemented' should be 'the ones that were implemented', and 'only 18 connections where longer' should be 'only 18 connections were longer'.
  3. [Figure 5] The legend entry 'No. Nodes' is ambiguous because the three curves refer to the assumed number of honest node IDs in the network (9000, 25000, 5e5), while the x-axis is the number of pre-computed adversary IDs; please clarify the axis and legend labels.
  4. [Section IV-B] The sentence 'The first step is always given when there is an adversarial node in each bucket' should be qualified: it holds when the bucket corresponding to the random lookup target is populated and the adversarial node is among the 16 closest known peers to that target, which is exactly the event analyzed later in Section V-B.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the attack mechanics are derived from Geth's source code and validated against live measurements, with no fitted parameter reused as a prediction.

full rationale

The central derivation is code-level and self-contained. Section IV's attack construction follows directly from Geth v1.8.0's peer-selection mechanics: ReadRandomNodes returns bucket heads (Sec. III-D/IV-A), the /24 subnet limits cap Sybils at two per bucket and ten per table (Sec. III-D), and lookups contact the 16 closest known nodes to a random target (Sec. III-E, Algorithm 1). The analytical part (Sec. V) computes Sybil-generation costs and FindNode-query probabilities from the uniformity of hashed ECDSA node IDs; no parameter is fitted to the later experiments and then reused as a prediction. The no-restart timeline rests on an empirical connection-duration trace (Sec. VI-C) and is separately validated by a live eclipse attempt (Sec. VI-C, 4.765 d after a 72 h warm-up); this is an empirical premise, not a circularly defined claim. The only overlapping-author citation is [2] (Tschorsch and Scheuermann), which is used as general background about blockchain network-layer assumptions and supplies no load-bearing result. No equation reduces to its own inputs by construction, and no fitted quantity is renamed as a prediction.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

We list no invented entities. The free parameters are attack configuration choices, not fitted scientific constants. The axioms are the uniform-hash assumption, the Geth v1.8.x behavior assumptions, and the empirical churn assumption. The Geth v1.9.0 countermeasure adoption provides external confirmation that the underlying behavior was real.

free parameters (2)
  • sybils per bucket = 1
    One adversarial node per bucket suffices to dominate ReadRandomNodes and to be queried during lookups. This is a design choice derived from Geth's k=16 bucket size, not a fitted constant.
  • precomputed node IDs = 5,000,000
    Chosen to make the probability of returning adversarial IDs in lookups nearly 1 (Eq. 15); not fitted to data, but a hand-picked resource level for the attack implementation.
assumptions (3)
  • domain assumption Keccak256 hashes of ECDSA public keys are uniformly distributed in the node ID space.
    Used in all probability derivations (Section V-A, V-B). If hashes were biased, the expected key generations and lookup probabilities would change.
  • domain assumption Geth v1.8.x ReadRandomNodes returns only the head of randomly chosen buckets.
    The attack on the direct-selection path depends on this implementation behavior; confirmed by code analysis and by the fact that Geth v1.9.0 changed it (Section VII-B.2).
  • domain assumption Existing honest connections drop frequently enough that no victim restart is required.
    The no-restart claim rests on a single 18.76-day measurement trace (Section VI-C); if real churn is lower, the timeline for eclipsing a long-running node grows substantially.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Eclipsing Ethereum Peers with False Friends." pith.science (2026). https://pith.science/paper/D57MFQV4

@misc{pith2026190810141,
  author       = {Pith},
  title        = {Pith review of: Eclipsing Ethereum Peers with False Friends},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/D57MFQV4}},
  note         = {Machine review of arXiv:1908.10141}
}
read the original abstract

Ethereum is a decentralized Blockchain system that supports the execution of Turing-complete smart contracts. Although the security of the Ethereum ecosystem has been studied in the past, the network layer has been mostly neglected. We show that Go Ethereum (Geth), the most widely used Ethereum implementation, is vulnerable to eclipse attacks, effectively circumventing recently introduced (Geth v1.8.0) security enhancements. We responsibly disclosed the vulnerability to core Ethereum developers; the corresponding countermeasures to our attack where incorporated into the v1.9.0 release of Geth. Our false friends attack exploits the Kademlia-inspired peer discovery logic used by Geth and enables a low-resource eclipsing of long-running, remote victim nodes. An adversary only needs two hosts in distinct /24 subnets to launch the eclipse, which can then be leveraged to filter the victim's view of the Blockchain. We discuss fundamental properties of Geth's node discovery logic that enable the false friends attack, as well as proposed and implemented countermeasures.

Figures

Figures reproduced from arXiv: 1908.10141 by the authors.

Figure 1
Figure 1. Overview of the Ethereum Network Stack. n > 0 free outbound slots Read bn/2c nodes from table Lookup￾buffer empty? Read n − bn/2c nodes from lookup￾buffer Lookup to random target yes no [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. How outbound connections are established. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Assume that the local node receives either a [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (4 more)
Figure 3
Figure 3. Figure 3: How nodes enter buckets. (cf. Section III-C) but instead uses the plain xor-metric. To illustrate, let N¯ 1, N¯ 2 be two node IDs and t a (random) target ID. For Ethereum (and likewise Kademlia), N¯ 1 is closer to t than N¯ 2 iff N¯ 1 ⊕ t < N¯ 2 ⊕ t, where ⊕ denotes th…
Figure 5
Figure 5. Figure 5: Probability that the lowest node ID is returned, depending on the [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Mean duration of node ID generation with different numbers of [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 8
Figure 8. Figure 8: Cumulative distribution of durations in the trace. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Unveiling Ethereum's P2P Network: The Role of Chain and Client Diversity

    cs.NI 2025-01 conditional novelty 6.0 of 10

    An instrumented Ethereum client reveals that only about 13% of discovered peers are fully mainnet-compatible and that client and chain diversity cause most connection failures and discovery timeouts.

  2. Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network

    cs.DC 2025-04 conditional novelty 5.0 of 10

    A timestamp-free, frequency-based inference method maps Monero's P2P network and finds it is highly centralized around about 14 supernodes.

Reference graph

Works this paper leans on

23 extracted references · 21 canonical work pages · cited by 2 Pith papers

  1. [6]

    Low-resource eclipse attacks on ethereum’s peer-to-peer network,

    Y . Marcus, E. Heilman, and S. Goldberg, “Low-resource eclipse attacks on ethereum’s peer-to-peer network,” IACR, vol. 236, 2018

    work page 2018

  2. [1]

    Eclipse attacks on bitcoin’s peer-to-peer network,

    E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse attacks on bitcoin’s peer-to-peer network,” in Proc. of USENIX Security Symposium, 2015

    work page 2015

  3. [2]

    Bitcoin and beyond: A technical survey on decentralized digital currencies,

    F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A technical survey on decentralized digital currencies,” IEEE Communications Surveys and Tutorials , vol. 18, no. 3, 2016

    work page 2016

  4. [3]

    Stubborn mining: Generalizing selfish mining and combining with an eclipse attack,

    K. Nayak, S. Kumar, A. Miller, and E. Shi, “Stubborn mining: Generalizing selfish mining and combining with an eclipse attack,” in Proc. of EuroS&P , IEEE, 2016

    work page 2016

  5. [4]

    Bitcoin: A peer-to-peer electronic cash system,

    S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008

    2008

  6. [5]

    Ethereum: A secure decentralised generalised transaction ledger,

    G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum project yellow paper , 2014

    work page 2014

  7. [7]

    Kademlia: A peer-to-peer informa- tion system based on the XOR metric,

    P. Maymounkov and D. Mazières, “Kademlia: A peer-to-peer informa- tion system based on the XOR metric,” in Proc. of IPTPS , Springer, 2002

    work page 2002

  8. [8]

    Measuring ethereum network peers,

    S. K. Kim, Z. Ma, S. Murali, et al. , “Measuring ethereum network peers,” in Proc. of IMC , ACM, 2018

    work page 2018

Show all 23 references
  1. [9]

    The sybil attack,

    J. R. Douceur, “The sybil attack,” in Peer-to-peer Systems, Springer, 2002

    2002

  2. [10]

    Poisoning the kad network,

    T. Locher, D. Mysicka, S. Schmid, and R. Wattenhofer, “Poisoning the kad network,” in Proc. of ICDCN , ACM, 2010

    2010

  3. [11]

    Bertoni, J

    G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche, “Keccak,” in Annual international conference on the theory and applications of cryptographic techniques, Springer, 2013

    2013

  4. [12]

    Ferguson, B

    N. Ferguson, B. Schneier, and T. Kohno, Cryptography engineering - design principles and practical applications . Wiley, 2010

    2010

  5. [13]

    J. E. Gentle, Computational statistics . Springer, 2009, vol. 308

    2009

  6. [14]

    Decentralization in bitcoin and ethereum networks,

    A. E. Gencer, S. Basu, I. Eyal, R. van Renesse, and E. G. Sirer, “Decentralization in bitcoin and ethereum networks,” CoRR, vol. abs/1801.03998, 2018. eprint: 1801.03998

    2018 arXiv

  7. [15]

    Eclipse attacks on overlay networks: Threats and defenses,

    A. Singh, T. Ngan, P. Druschel, and D. S. Wallach, “Eclipse attacks on overlay networks: Threats and defenses,” in Proc. of INFOCOM , IEEE, 2006

    2006

  8. [16]

    Secure routing for structured peer-to-peer overlay networks,

    M. Castro, P. Druschel, A. J. Ganesh, A. I. T. Rowstron, and D. S. Wallach, “Secure routing for structured peer-to-peer overlay networks,” in Proc. of OSDI , USENIX Association, 2002

    2002

  9. [17]

    Security considerations for peer-to-peer distributed hash tables,

    E. Sit and R. T. Morris, “Security considerations for peer-to-peer distributed hash tables,” in Prof. of IPTPS , Springer, 2002

    2002

  10. [18]

    Mitigating eclipse attacks in peer-to-peer networks,

    D. Germanus, S. Roos, T. Strufe, and N. Suri, “Mitigating eclipse attacks in peer-to-peer networks,” in Proc. of CNS , IEEE, 2014

    2014

  11. [19]

    Exploiting KAD: possible uses and misuses,

    M. Steiner, T. En-Najjary, and E. W. Biersack, “Exploiting KAD: possible uses and misuses,” CCR, vol. 37, no. 5, 2007

    2007

  12. [20]

    Conducting and optimizing eclipse attacks in the kad peer-to-peer network,

    M. Kohnen, M. Leske, and E. P. Rathgeb, “Conducting and optimizing eclipse attacks in the kad peer-to-peer network,” in Proc. of IFIP NETWORKING, Springer, 2009

    2009

  13. [21]

    Attacking the kad network - real world evaluation and high fidelity simulation using DVN,

    P. Wang, J. Tyra, E. Chan-Tin, et al. , “Attacking the kad network - real world evaluation and high fidelity simulation using DVN,”Security and Communication Networks , vol. 6, no. 12, 2013

    2013

  14. [22]

    Hijacking bitcoin: Routing attacks on cryptocurrencies,

    M. Apostolaki, A. Zohar, and L. Vanbever, “Hijacking bitcoin: Routing attacks on cryptocurrencies,” in Proc. of S&P , IEEE, 2017

    2017

  15. [23]

    Ethereum eclipse attacks,

    A. Gervais and K. Wüst, “Ethereum eclipse attacks,” ETH Zurich, 2016

    2016

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.