{"id":"2b2e59e5-6e4b-4e54-892c-f51d87ab5f7e","arxiv_id":"1908.10141","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A low-resource 'false friends' attack can eclipse Geth nodes without a restart by inserting one fake peer per routing bucket and flooding lookups with precomputed node IDs.","lead":"An attacker can quietly take over all of an Ethereum node's network connections using only two IP addresses, cutting the node off from honest peers. The trick exploits detailed quirks in how Geth, the main Ethereum software, chooses its friends.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The no-restart timeline is the load-bearing empirical premise: Section VI-C logs all connections, but the attack needs outbound slots to turn over, and a single 4.765-day success is thin support.","rationale":"After reviewing the full text, the attack mechanics are largely sound. The one-Sybil-per-bucket takeover of ReadRandomNodes is consistent with Geth v1.8's bucket-head selection; the 'always queried' lookup argument holds because the bucket containing the target shares a longer prefix with the target than any other bucket, and the 16-node bucket cap guarantees inclusion. The precomputed-ID analysis is under-specified (Eq. 15 bounds only the minimum order statistic, not all 16 slots), but the attack's iterative lookup and 12-node responses make the 16-slot takeover overwhelmingly likely; this is a presentation gap, not a correctness risk. The genuinely load-bearing weak spot is the no-restart timeline. The aggregate connection-duration CDF in Section VI-C does not isolate outbound slots, and the no-restart attack was demonstrated once. If outbound connections are longer-lived than the mixed CDF suggests, the headline time-to-eclipse claim fails even though the underlying mechanism is real. The reader's CONDITIONAL verdict is appropriate; no stronger action is needed.","tokens_in":14941,"tokens_out":19732,"duration_ms":223283,"concrete_test":"Re-run the no-restart attack on at least five Geth v1.8.20 nodes that have been live for more than 30 days, while instrumenting the node to log inbound versus outbound connection durations separately. Report the outbound-only 95th percentile and the time until all 8 outbound slots first turn over. If the outbound 95th percentile is also below 5.5 d and all five experiments complete in under 10 d, the 'matter of days' claim stands; if any node retains one outbound connection beyond the reported eclipse time, the claim should be qualified to 'typically days, sometimes much longer'.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that a long-running, remote node can be eclipsed 'in a matter of days' without a restart depends on the empirical premise that peer churn frees the victim's outbound slots quickly. The paper supports this with one 18.76-day trace (Section VI-C), but the trace logs every connection and excludes 90.26% of connections shorter than 60 s; it does not separate inbound from outbound connections. Inbound connections are unvetted and ephemeral, so the aggregate CDF can be dominated by inbound churn. The attack, however, can only complete when all 8 outbound slots are replaced by adversary nodes; outbound connections are deliberately dialed and may be far longer-lived. The only direct no-restart evidence is a single successful experiment (4.765 d after a 72 h warm-up). If outbound durations have heavier tails on genuinely long-running nodes, the no-restart eclipse time grows from days to weeks or months, and the main novel differentiator from the restart-based attack of [6] weakens. This is not an internal inconsistency; it is an under-supported empirical load-bearing premise. The paper's own countermeasure discussion (Section VII-B1) concedes that raising max peers increases the chance of sustaining a long-lived honest connection, which shows the sensitivity.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":15135,"tokens_out":11095,"duration_ms":110070,"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":[{"comment":"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.","section":"Section VI-C and the no-restart experiment"},{"comment":"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.","section":"Section V-B2, Eqs. (8)-(12)"}],"minor_comments":[{"comment":"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.","section":"Section VI-C"},{"comment":"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'.","section":"Section VII-A and VI-C"},{"comment":"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.","section":"Figure 5"},{"comment":"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.","section":"Section IV-B"}],"recommendation":"major_revision","confidential_remarks":"The paper is a solid empirical security contribution and the responsible disclosure is commendable. The two load-bearing gaps are the missing order-statistic analysis for the lookup-buffer and the insufficiently supported no-restart timeline. If the authors can fix the analysis and strengthen the empirical case, the paper would be suitable for publication; otherwise the central 'matter of days without restart' claim should be scaled back."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe one thing to know: this is a real eclipse attack on Geth, with a genuinely new mechanism that works against a long-running victim using only two IP addresses. The core idea is one Sybil node per Kademlia bucket, not a full table flood, plus precomputed node IDs to dominate the lookup-buffer. The authors backed it with live mainnet runs and the Geth team shipped countermeasures in v1.9.0 in response. That is a meaningful result, not incremental filler.\n\nWhat it does well: the analysis of Geth's peer selection is the most detailed I've seen, and the bucket-entry math (geometric expectation ~262k key generations) is correct. The probability of getting a FindNode request is derived cleanly. The restarted-victim evaluation is solid: 45/50 eclipses within 24h, median just over an hour. The related work is honest, and the paper is self-contained; the shared-author survey cite is only background.\n\nWhere the soft spots are: the no-restart claim is the one load-bearing empirical premise, and it is thinner than the headline suggests. The connection-duration trace is one 18.76-day run; it discards 90% of connections under 60 seconds and does not separate inbound from outbound. The attack needs outbound slots to turn over, while inbound slots are trivially fillable, so the aggregate CDF can overstate the relevant churn. The single successful no-restart attack (4.765 days) and two near-misses are suggestive, not proof; if outbound connections on genuinely long-running nodes are longer-lived, the 'matter of days' becomes weeks or months. The paper's own countermeasure discussion concedes the sensitivity when it notes that raising max peers increases the chance of a long-lived honest connection. There's also a minor theoretical gap: the lookup-buffer takeover is proven for the minimum order statistic, not all 16 slots, though with 5e6 precomputed IDs the practical probability is overwhelming.\n\nNone of this kills the contribution. The attack against restarted victims is well supported, and the one-Sybil-per-bucket mechanism is new regardless of the churn timeline. A revision should add outbound-only connection statistics, more no-restart experiments, and ideally the trace data.\n\nThis paper deserves a serious referee. I'd take it to reading group and would cite it in my own work.\n\nSend it out, with a request for the missing data.","headline":"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.","tokens_in":15715,"tokens_out":2554,"would_cite":true,"duration_ms":23906,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["eclipse attack","Ethereum","Geth","peer discovery","Kademlia","Sybil attack","lookup-buffer","blockchain network security"],"falsifier":"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.","tokens_in":14691,"feed_emoji":"⛓️","tokens_out":5748,"duration_ms":52528,"temperature":0.7,"pith_summary":"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.","feed_headline":"Two IPs can eclipse Ethereum nodes in days","feed_subtitle":"A new Geth attack plants one fake peer per bucket and needs no victim restart to filter the chain.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Prior low-resource eclipse attack on Geth's discovery table that requires a victim restart and full-table flooding; the baseline this paper's attack improves upon.","marker":"[6]"},{"why":"Kademlia DHT specification providing the XOR metric, k-buckets, and iterative lookup procedure that Geth's discv4 adapts.","marker":"[7]"},{"why":"Measurement study of the Ethereum network reporting node-ID counts and protocol heterogeneity, used to size the number of honest IDs and explain the abundance of short-lived connections.","marker":"[8]"},{"why":"Sybil attack formulation establishing that identities are cheap to create; underpins the low cost of generating attacker node IDs.","marker":"[9]"},{"why":"Eclipse attack on Bitcoin's peer-to-peer network, the original demonstration that eclipsing a blockchain peer enables double spending and related attacks.","marker":"[1]"},{"why":"Stubborn mining, a follow-up attack that combines selfish mining with an eclipse; cited as a consequence of eclipsing a victim node.","marker":"[3]"}],"fun_headline_variants":["Two IPs eclipse Geth nodes in days","False Friends: low-cost Geth eclipse attack","Geth eclipse: no restart, just 2 IPs","5M fake IDs let 2 IPs filter Ethereum chain","Eclipse via Kademlia: Geth v1.8 exposed"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Two IPs eclipse Geth nodes in days","False Friends: low-cost Geth eclipse attack","Geth eclipse: no restart, just 2 IPs","5M fake IDs let 2 IPs filter Ethereum chain","Eclipse via Kademlia: Geth v1.8 exposed"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000156,"raw_usage":{"total_tokens":1211,"prompt_tokens":933,"completion_tokens":278,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":549,"completion_tokens_details":{"reasoning_tokens":196}},"tokens_in":549,"tokens_out":278,"duration_ms":3658,"temperature":1.0,"reasoning_tokens":196,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T10:52:27.223194+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Low-resource eclipse attacks on ethereum’s peer-to-peer network,","cited_arxiv_id":null,"evidence_quote":"Prior low-resource eclipse attack on Geth's discovery table that requires a victim restart and full-table flooding; the baseline this paper's attack improves upon."},{"cited_title":"Kademlia: A peer-to-peer informa- tion system based on the XOR metric,","cited_arxiv_id":null,"evidence_quote":"Kademlia DHT specification providing the XOR metric, k-buckets, and iterative lookup procedure that Geth's discv4 adapts."},{"cited_title":"Measuring ethereum network peers,","cited_arxiv_id":null,"evidence_quote":"Measurement study of the Ethereum network reporting node-ID counts and protocol heterogeneity, used to size the number of honest IDs and explain the abundance of short-lived connections."},{"cited_title":"The sybil attack,","cited_arxiv_id":null,"evidence_quote":"Sybil attack formulation establishing that identities are cheap to create; underpins the low cost of generating attacker node IDs."},{"cited_title":"Eclipse attacks on bitcoin’s peer-to-peer network,","cited_arxiv_id":null,"evidence_quote":"Eclipse attack on Bitcoin's peer-to-peer network, the original demonstration that eclipsing a blockchain peer enables double spending and related attacks."},{"cited_title":"Stubborn mining: Generalizing selfish mining and combining with an eclipse attack,","cited_arxiv_id":null,"evidence_quote":"Stubborn mining, a follow-up attack that combines selfish mining with an eclipse; cited as a consequence of eclipsing a victim node."}],"review_version":1}