Pith. sign in

REVIEW 4 major objections 8 minor 25 references

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

T0 review · 4 major / 8 minor · reviewed 2026-08-16 · 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 Monero's timestamp-free peer protocol still leaks its structure: clustering how often addresses recur in received peer lists reveals a network dominated by 14 supernodes that reach 82.1 percent of nodes.

desk verdict A promising but incomplete timestamp-free neighbor-inference method for Monero: solid precision evidence, missing recall, and topology claims that go beyond what the data support. read the letter →

arxiv 2504.15986 v1 pith:HQHERUKE submitted 2025-04-22 cs.DC

Yu Gao , Matija Piškorec , Yu Zhang , Nicolò Vallarano , Claudio J. Tessone This is my paper · ORCID
classification cs.DC
keywords Moneropeer-to-peernetworkpeerlistinferencek-meansclusteringtimestamp-freeprotocoltopologysupernodesrobustnessTCPflowanalysis
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

Monero's privacy-focused peer protocol removed the timestamps that earlier work used to infer who is connected to whom, and this paper tries to close that gap. Its claim is that a real neighbor appears in the peer lists a node receives about 0.833 of the time, while a random address appears about 0.252 of the time, so simply counting appearances and splitting the counts with k-means clustering separates the true links. The authors validate the inference against the actual connection lists of their three observation nodes and report precision between 68.73 and 82.99 percent, with longer observation improving accuracy. If the method holds, the visible Monero network is substantially centralized: 14 high-degree nodes attach directly to 3,153 of 4,837 nodes, and removing roughly 9.4 percent of nodes by betweenness centrality breaks the largest connected component. That matters because the anonymity layer is often assumed to hide such structure, and a centralized core is a potential target for partitioning or eclipse-style attacks.

What carries the argument

The load-bearing mechanism is the relative-presence frequency $p_i(a) = \frac{1}{n_i}\sum_{j=1}^{n_i}\chi(a \in P_j)$, the fraction of TCP peer-list packets received by node $i$ that contain address $a$. Because Monero's handshake returns a near-uniform draw from the top-300 whitelist, a genuine neighbor appears with probability $P_{\text{neighbour}} \approx 0.833$, whereas a non-neighbor appears with $P_{\text{random}} = P_{\text{enter}} \cdot P_{\text{selected}} \approx 0.302 \times 0.833 \approx 0.252$. The roughly threefold gap is what k-means clustering detects, and this frequency-separation step is what converts raw peer-list mentions into an inferred edge set.

What would settle it

Run a Monero node whose neighbors are fully known, record every received peer-list packet for at least a week, and compare the empirical appearance frequencies of known neighbors with those of addresses known to be non-neighbors; if the distributions overlap strongly, or if the same sender's peer-list entries are ordered by recency, the 0.833/0.252 gap and hence the k-means split do not recover true edges. The same experiment can also measure recall, which the paper does not report.

Watch

Extended reading notes

Core claim

Using passive TCP flow captures on three geographically separate Monero nodes, the paper's central discovery is that the updated timestamp-free protocol does not defeat neighbor inference. When a node returns 250 entries from its top-300 whitelist during handshakes, known neighbors are selected with probability about 0.833, while a random address must first enter the top 300 (probability about 0.302) and then be selected (probability about 0.833), giving about 0.252. The authors turn this ratio into an algorithm: count each address's relative presence across all received peer lists, discard counts of one, run k-means with k=2 within each source IP's count set, and keep the high-frequency cluster. Across their three nodes, 68.73 to 82.99 percent of the inferred neighbors matched the connection lists reported by the daemon, and the EU node's precision rose from 69.48 to 80.22 percent when the observation window grew from one to three weeks. Applying the inferred edge set to the whole collection yields a 4,837-node network in which 14 top-degree nodes connect directly to 82.1 percent of the nodes, share over 91 percent of their one-hop neighbor sets with each other, and whose removal by betweenness centrality collapses the largest component at 9.4 percent removal.

Load-bearing premise

The whole inference rests on a single ratio: real neighbors are about 3.3 times more likely than random addresses to appear in received peer lists, which holds only if Monero's peer-list sharing draws near-uniformly from a top-300 whitelist; if that sharing is ordered, recency-biased, or otherwise non-uniform, the clusters stop being neighbors.

Editorial extensions

If this is right

  • Monero can be mapped without timestamps: longer passive listening raises precision, from 69.48 percent to 80.22 percent for the EU node when the window goes from one week to three weeks.
  • The visible network is core-periphery rather than flat: 14 top-degree nodes attach directly to 3,153 of 4,837 nodes, so most nodes are within one hop of a small hub set.
  • The core is internally redundant: over 91 percent of each top-degree node's one-hop neighbors are shared with other top-degree nodes, and 9 of the 14 nodes have near-100 percent overlap.
  • Centrality-based attacks are efficient: removing 9.4 percent of nodes by betweenness centrality, or 12 percent by degree, reduces the largest connected component to near zero.
  • The inferred map's accuracy holds across continents: precision runs 79.35 percent for Singapore, 68.73 percent for the US, and 69.48 percent for the EU on one-week data, improving to 82.99, 73.00, and 80.22 percent on three-week data.

Reading between the lines

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

  • A direct test the authors do not report is measuring how uniformly Monero actually samples its top-300 whitelist; if a peer orders entries by recency or uses a recency-weighted selection, the 0.833/0.252 gap would narrow or shift, and k-means would find clusters on a different axis.
  • The same frequency-separation recipe should transfer to other P2P protocols that hide timestamps but share a bounded whitelist subset; the only requirement is a stable recurrence gap between real neighbors and random addresses, so testing it on another timestamp-hiding coin would extend the method.
  • The precision numbers likely understate the true quality, because the benchmark real connection list is only a transient snapshot: an inferred edge to a peer that disconnected just before the RPC snapshot is counted as a false positive even if it was genuine during the listening window.
  • The betweenness-collapse result implies a concrete attack surface: if an adversary can control or eclipse a handful of high-betweenness supernodes, partitioning the Monero network may be feasible despite the high overlap among hubs; the paper's robustness framing describes the vulnerability without proposing a mitigation.
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

4 major / 8 minor

Summary. The paper proposes a method to infer peer-to-peer connections in the Monero network under its updated protocol that removes timestamps from peer lists. The authors collect TCP flow data at three nodes on three continents for three weeks, extract peer-list frequencies, filter low-count rows, and apply per-source k-means clustering (k=2) to separate 'true' high-frequency neighbors from noise. They validate precision against RPC-reported connection lists for their own nodes, reporting 68.73--82.99% precision. Using the inferred edge set, they map a 4,837-node largest connected component, identify 14 top-degree supernodes covering 82.1% of nodes, and simulate targeted removal by degree and betweenness centrality. They conclude that the Monero P2P network is highly centralized and that removing about 9.4--12% of nodes collapses the largest connected component.

Significance. If the inferred edge set were validated, this would be a useful contribution: it addresses a gap left by the protocol change, provides a measurement methodology independent of RPC, and offers concrete topology and robustness findings for Monero. The paper's strengths include real deployment on three continents, three weeks of data, an external benchmark via monero-daemon-rpc, and the observation that precision improves with longer observation windows. However, because recall is never measured and validation covers only edges incident to the authors' own three nodes, the global topology and robustness claims are currently under-supported. The central method is plausible and the missing quantities are computable from the authors' own data, so the issues are fixable within the scope of the manuscript.

major comments (4)
  1. [Section III-D, Tables I and II] Recall is defined in the text but never measured. The validation procedure computes precision only as the fraction of inferred neighbors that appear in the RPC connection lists, and the tables report 'Inferred network neighbors' and 'Neighbors in connection list' but not the total number of actual neighbors. Without recall, D' may be a high-precision, low-recall subgraph that systematically omits true low-frequency edges. This matters directly for Section IV, where D' is treated as the complete graph for the 82.1% hub-coverage and 9.4% collapse claims; a low-recall edge set biased toward repeated handshakes would inflate degree centralization and apparent fragility. The authors should report recall for their three validation nodes and, if recall is low, re-examine the topology conclusions.
  2. [Section III-C, Algorithm 1] The k-means step with k=2 always partitions any multiset of count values into two clusters, so the existence of a 'high-frequency cluster' is not by itself evidence of a real bimodal separation. The thresholds Cmin=2, Nmin=8, and k=2 are hand-set, and the paper provides no sensitivity analysis or null-model comparison. For example, a source with only low count values such as {2,3,4} will still be split, and the higher-count values will be labeled true neighbors by construction. The authors should demonstrate that the separation is robust across threshold choices and, ideally, compare against a null model in which peer-list entries are permuted.
  3. [Section III-B] The frequency-separation argument rests on the assumed probabilities Pneighbour≈0.833 and Prandom≈0.252, which in turn assume uniform draws from the top-300 whitelist and a fixed entry probability Penter≈0.302. No empirical evidence or citation is provided for these values. If Monero's actual peer-list sharing is ordered, biased toward recently seen addresses, or otherwise non-uniform, the threefold gap disappears and k-means separates on an axis unrelated to neighbor status. Because this assumption supports every inferred edge in the network, it should be validated directly, for instance by measuring the empirical frequency distributions on the authors' own nodes and by reporting the false-negative rate.
  4. [Section IV] Validation is performed only for edges incident to the authors' three nodes, but the topology analysis in Section IV uses D' for all nodes, including edges between third-party peers that are never checked against ground truth. The reported precision numbers therefore do not validate the global edge set used for the supernode overlap and attack-robustness results. The authors should either obtain additional ground truth for a sample of non-ego edges or clearly state that the global topology conclusions rest on unvalidated inferred edges and temper the corresponding claims.
minor comments (8)
  1. [Section IV-3] The text says the network 'demonstrates strong resilience' but then reports that removing 9.4% of nodes by betweenness centrality collapses the LCC to nearly zero; this characterization appears internally inconsistent and should be reworded.
  2. [Figure 3] The heatmap shows overlap rates of one-hop neighbor sets, but the text interprets values above 0.91 as 'each top-degree node's direct neighbors are connected to other top-degree nodes'; neighbor-set overlap does not imply direct connectivity between those neighbors and other supernodes.
  3. [Algorithm 1 and Section III-C text] The text in Section III-C says groups with fewer than two interactions were discarded, while Algorithm 1 line 6 imposes Nmin=8; please make the group-size threshold consistent and explicit.
  4. [Section II and Section III-B1] The protocol description says a peer returns '120% of peers from its top 300 last seen peers', while the data-collection section says each peer 'shares up to 250 entries from its top 300 whitelist peers'; these numbers should be reconciled with the protocol source.
  5. [Reference list] Reference [1] (Eason et al., 1955) appears unrelated to distributed-ledger technology and may be a placeholder; please replace it with an appropriate citation for the first paragraph.
  6. [Author list] The second author's name is typeset as 'Pi ˇskorec' in the author block; it should be 'Piškorec'.
  7. [Abstract] The abstract claims 'the first to reveal connectivity patterns in Monero's updated protocol'; given prior work by Cao et al. [17] on the Monero P2P network, please qualify the novelty claim as applying to the updated timestamp-free protocol.
  8. [Section III-B1] In the definition of pi(a), the notation ni is used but not defined; please define it as the total number of received peer lists for node i.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the neighbor inference is validated against an independent monero-daemon-rpc connection-list benchmark, and the thresholds and k-means split are not fitted to the validation labels.

full rationale

The paper's central derivation is self-contained rather than circular. The inference pipeline (Algorithm 1) removes rows with count ≤ 1, groups by source IP, and applies k-means with k=2 to the unique count values in each group, labeling the higher-frequency cluster as true neighbors. The validation step then compares these inferred neighbors with real connection lists obtained via monero-daemon-rpc, which is an externally observable ground truth independent of the peer-list frequencies used by the algorithm. No parameter is fitted to the validation labels: Cmin=2 and Nmin=8 are stated protocol/design thresholds, and the k-means split is unsupervised on count values alone. The precision figures in Tables I and II are therefore not forced by construction; a random split or a frequency threshold chosen to match the connection lists would be circular, but that is not what the paper does. The frequency-separation argument (P_neighbour ≈ 0.833 vs Prandom ≈ 0.252) is a protocol-level justification for why a high-frequency cluster should exist, not a restatement of the validation outcome. The main weakness is external validity rather than circularity: the paper defines recall but never reports it, and the topology claims (e.g., 4,837 nodes, 14 supernodes covering 82.1%, LCC collapse at 9.4% removal) are built from the high-frequency edge set without measuring false negatives. If many true edges occur at low frequency and are discarded by the count threshold or assigned to the low-frequency cluster, the inferred graph could be a high-precision but low-recall subgraph, and the centralization and fragility conclusions could be overstated. That is a correctness or completeness concern, not a reduction of the output to the input by definition. There are no load-bearing self-citations, no imported uniqueness theorems, no ansatz smuggled in via citation, and no renamed known result. Accordingly, no circular step meeting the required evidentiary standard can be identified, and the appropriate circularity score is 0.

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

The inference depends on domain assumptions about Monero protocol behavior (uniform peer-list sharing, persistent handshakes, RPC ground truth, port-18080 completeness) and on three hand-set thresholds (Cmin=2, Nmin=8, k=2). No new physical or mathematical entities are postulated.

free parameters (3)
  • Cmin = 2
    Minimum co-occurrence count to keep an edge; chosen by hand as a noise filter, not derived from protocol or data. Changes which pairs enter clustering.
  • Nmin = 8
    Minimum number of distinct peers per source IP before k-means is applied; set to Monero's default outgoing connection count but used as a group-size filter.
  • k = 2
    Number of clusters in k-means; assumes exactly two frequency populations (neighbors and non-neighbors). If the frequency distribution has more modes, labels will be wrong.
assumptions (4)
  • domain assumption Real neighbors maintain frequent handshakes and therefore appear more often in shared peer lists than non-neighbors.
    Used in Section III-B as the basis for frequency separation.
  • domain assumption Peer list entries are sampled near-uniformly from the top-300 whitelist, so each handshake includes each neighbor with probability about 0.833 and each random peer with probability about 0.252.
    Underpins the claim that real neighbors appear about three times more often than random peers; not empirically verified.
  • domain assumption The monero-daemon-rpc connection list provides an accurate snapshot of true neighbors during the collection window.
    Used as ground truth in Section III-D; transient connections may make this benchmark noisy.
  • domain assumption TCP flows captured on port 18080 contain all relevant peer-list exchanges.
    Assumes no peer-list data arrives through other ports or is missed by tcpflow.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network." pith.science (2026). https://pith.science/paper/HQHERUKE

@misc{pith2026250415986,
  author       = {Pith},
  title        = {Pith review of: Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HQHERUKE}},
  note         = {Machine review of arXiv:2504.15986}
}
read the original abstract

The Monero blockchain enables anonymous transactions through advanced cryptography in its peer-to-peer network, which underpins decentralization, security, and trustless interactions. However, privacy measures obscure peer connections, complicating network analysis. This study proposes a method to infer peer connections in Monero's latest protocol version, where timestamp data is unavailable. We collect peerlist data from TCP flows, validate our inference algorithm, and map the network structure. Our results show high accuracy, improving with longer observation periods. This work is the first to reveal connectivity patterns in Monero's updated protocol, providing visualizations and insights into its topology. Our findings enhance the understanding of Monero's P2P network, including the role of supernodes, and highlight potential protocol and security improvements.

Figures

Figures reproduced from arXiv: 2504.15986 by the authors.

Figure 1
Figure 1. Data collection pipeline. • Typical nodes: default 8 outgoing neighbors. The challenge is to set a frequency threshold to distinguish real neighbors. Since peer selection is bidirectional and is governed by the IDLE_HANDSHAKE protocol, real neighbors are expected to appear consistently in updated whitelists. For a node i, we define the relative presence of an observed address a as: pi(a) = Pni j=1 χ(a ∈ Pj ) ni wher… view at source ↗
Figure 2
Figure 2. Visualization of the LCC, with node colors representing [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. LCC attack by removing high betweenness and degree [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (1 more)
Figure 3
Figure 3. Figure 3: One-hop neighbor overlap rate among the 14 top-degree [PITH_FULL_IMAGE:figures/full_fig_p004_3.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 16 canonical work pages

  1. [1]

    On certain integrals of lipschitz- hankel type involving products of bessel functions,

    G. Eason, B. Noble, and I. N. Sneddon, “On certain integrals of lipschitz- hankel type involving products of bessel functions,” Philosophical Transactions of the Royal Society of London. Series A, Mathematical and Physical Sciences , vol. 247, no. 935, pp. 529–551, 1955

    1955

  2. [2]

    Ethereum: A secure decentralised generalised trans- action ledger,

    G. Wood et al. , “Ethereum: A secure decentralised generalised trans- action ledger,” Ethereum project yellow paper , vol. 151, no. 2014, pp. 1–32, 2014

    2014

  3. [3]

    Bitcoin: Economics, technology, and governance,

    R. B ¨ohme, N. Christin, B. Edelman, and T. Moore, “Bitcoin: Economics, technology, and governance,” Journal of economic Perspectives, vol. 29, no. 2, pp. 213–238, 2015

    work page 2015

  4. [4]

    A. M. Antonopoulos and D. A. Harding, Mastering bitcoin. ” O’Reilly Media, Inc.”, 2023

    work page 2023

  5. [5]

    A review of distributed ledger technologies,

    N. El Ioini and C. Pahl, “A review of distributed ledger technologies,” in On the Move to Meaningful Internet Systems. OTM 2018 Conferences: Confederated International Conferences: CoopIS, C&TC, and ODBASE 2018, Valletta, Malta, October 22-26, 2018, Proceedings, Part II . Springer, 2018, pp. 277–288

    work page 2018

  6. [6]

    Buford, H

    J. Buford, H. Yu, and E. K. Lua, P2P networking and applications . Morgan Kaufmann, 2009

    work page 2009

  7. [7]

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

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

    2008

  8. [8]

    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 Cryptology ePrint Archive , vol. 2018, no. 236, 2018

    work page 2018

Show all 25 references
  1. [9]

    A first look at browser-based cryptojacking,

    S. Eskandari, A. Leoutsarakos, T. Mursch, and J. Clark, “A first look at browser-based cryptojacking,” in 2018 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, 2018, pp. 58–66

    2018

  2. [10]

    Sok: cryptojacking malware,

    E. Tekiner, A. Acar, A. S. Uluagac, E. Kirda, and A. A. Selcuk, “Sok: cryptojacking malware,” in 2021 IEEE European Symposium on Security and Privacy (EuroS&P) . IEEE, 2021, pp. 120–139

    2021

  3. [11]

    Smart contract development: Challenges and opportunities,

    W. Zou, D. Lo, P. S. Kochhar, X.-B. D. Le, X. Xia, Y . Feng, Z. Chen, and B. Xu, “Smart contract development: Challenges and opportunities,” IEEE transactions on software engineering , vol. 47, no. 10, pp. 2084– 2106, 2019

    2019

  4. [12]

    An overview on smart contracts: Challenges, advances and platforms,

    Z. Zheng, S. Xie, H.-N. Dai, W. Chen, X. Chen, J. Weng, and M. Imran, “An overview on smart contracts: Challenges, advances and platforms,” Future Generation Computer Systems , vol. 105, pp. 475–491, 2020

    2020

  5. [13]

    Comparative analysis of blockchain consensus algorithms,

    L. M. Bach, B. Mihaljevic, and M. Zagar, “Comparative analysis of blockchain consensus algorithms,” in 2018 41st international convention on information and communication technology, electronics and micro- electronics (MIPRO). Ieee, 2018, pp. 1545–1550

    2018

  6. [14]

    Sok: Decentralized finance (defi),

    S. Werner, D. Perez, L. Gudgeon, A. Klages-Mundt, D. Harz, and W. Knottenbelt, “Sok: Decentralized finance (defi),” in Proceedings of the 4th ACM Conference on Advances in Financial Technologies , 2022, pp. 30–46

    2022

  7. [15]

    An empirical analysis of traceability in the monero blockchain,

    M. M ¨oser, K. Soska, E. Heilman, K. Lee, H. Heffan, S. Srivastava, K. Hogan, J. Hennessey, A. Miller, A. Narayanan et al., “An empirical analysis of traceability in the monero blockchain,” arXiv preprint arXiv:1704.04299, 2017

    2017 arXiv

  8. [16]

    Traceable monero: Anonymous cryptocurrency with enhanced accountability,

    Y . Li, G. Yang, W. Susilo, Y . Yu, M. H. Au, and D. Liu, “Traceable monero: Anonymous cryptocurrency with enhanced accountability,” IEEE Transactions on Dependable and Secure Computing, vol. 18, no. 2, pp. 679–691, 2019

    2019

  9. [17]

    Exploring the monero peer-to-peer network,

    T. Cao, J. Yu, J. Decouchant, X. Luo, and P. Verissimo, “Exploring the monero peer-to-peer network,” in Financial Cryptography and Data Security: 24th International Conference, FC 2020, Kota Kinabalu, Malaysia, February 10–14, 2020 Revised Selected Papers 24. Springer, 2020, p...

    2020

  10. [18]

    Newman, Networks

    M. Newman, Networks. Oxford university press, 2018

    2018

  11. [19]

    Networks, dynamics, and the small-world phenomenon,

    D. J. Watts, “Networks, dynamics, and the small-world phenomenon,” American Journal of sociology , vol. 105, no. 2, pp. 493–527, 1999

    1999

  12. [20]

    Eclipsing ethereum peers with false friends,

    S. Henningsen, D. Teunis, M. Florian, and B. Scheuermann, “Eclipsing ethereum peers with false friends,” arXiv preprint arXiv:1908.10141 , 2019

    1908 arXiv

  13. [21]

    Step by step towards creating a safe smart contract: Lessons and insights from a cryptocurrency lab,

    K. Delmolino, M. Arnett, A. Kosba, A. Miller, and E. Shi, “Step by step towards creating a safe smart contract: Lessons and insights from a cryptocurrency lab,” in Financial Cryptography and Data Security: FC 2016 International Workshops, BITCOIN, VOTING, and WAHC, Christ Chur...

    2016

  14. [22]

    Springer, 2016, pp. 79–94

    2016

  15. [23]

    Sybil- resistant mixing for bitcoin,

    G. Bissias, A. P. Ozisik, B. N. Levine, and M. Liberatore, “Sybil- resistant mixing for bitcoin,” in Proceedings of the 13th Workshop on Privacy in the Electronic Society , 2014, pp. 149–158

    2014

  16. [24]

    A blockchain construct for energy trading against sybil attacks,

    U. Asfia, V . Kamuni, S. Sutavani, A. Sheikh, S. Wagh, and N. M. Singh, “A blockchain construct for energy trading against sybil attacks,” in 2019 27th Mediterranean Conference on Control and Automation (MED). IEEE, 2019, pp. 422–427

    2019

  17. [25]

    Denial-of-service attacks rip the internet,

    L. Garber, “Denial-of-service attacks rip the internet,” computer, vol. 33, no. 04, pp. 12–17, 2000

    2000

Pith tools

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