Pith. sign in

REVIEW 5 major objections 7 minor 33 references

Deanonymizing Monero Transactions in Tor Network

T0 review · 5 major / 7 minor · reviewed 2026-07-09 · glm-5.2

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

Pith's one-line read Monero's Tor shield leaks: transactions traced to source IPs

desk verdict Real protocol-level vulnerabilities in Monero-over-Tor, but no end-to-end demonstration — the abstract overstates what was shown. read the letter →

arxiv 2607.07062 v1 pith:UEY2FHVO submitted 2026-07-08 cs.CR cs.ET

Ruisheng Shi , Shihan Zhang , Yulian Ge , Lina Lan , Qingfeng Zhang , Qin Wang This is my paper · ORCID
classification cs.CRcs.ET
keywords monerotransactionsnetworknodenodesoriginateddeanonymizationdeanonymizing
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

This paper identifies a structural flaw in how Monero routes transactions through Tor hidden service nodes. When a Monero node operating over Tor creates a new transaction, the protocol forwards it exclusively through two selected hidden service peers (called proxy nodes) before it reaches the public internet. An adversary who can position hidden service nodes as these proxies can capture the transaction, identify it as originated rather than relayed, and then link the Tor-level identifier to a real IP address by embedding timing-based watermarks in Monero protocol messages detectable at a malicious Tor entry relay. The paper demonstrates each of the three pipeline stages separately on live Tor and Monero networks: role identification via onion address repetition in peer lists achieves 100% precision and recall, connection occupation captures 7-11 of 12 outbound connections, proxy selection bias raises adversary proxy selection from 15.3% to 35.7% with one occupied connection, and watermarking achieves 100% precision with 91-94% recall. The core mechanism is a mismatch between Monero's forwarding policy, which assigns different roles to public and hidden-service connections, and Tor's connection model, which was designed to hide endpoints but cannot prevent protocol-level leakage from the application running on top of it.

What carries the argument

ProxyMark, a three-stage pipeline: (Stage 1) Node role identification via onion-address repetition analysis in Timed Sync Response messages; (Stage 2) Originated transaction identification via graylist/whitelist filling for outgoing connection occupation combined with falsified block-height advertisement for proxy selection bias; (Stage 3) Node location deanonymization via role-specific watermarking where Timed Sync Request message counts in fixed time windows encode binary identifiers, detected at a malicious Tor entry relay observing encrypted cell timing patterns.

What would settle it

A complete end-to-end demonstration on the live Monero mainnet where a specific transaction is captured by the adversary's proxy node, its Tor-level identifier is watermarked, and that identifier is detected at a malicious Tor entry relay that simultaneously observes the source IP address, all without controlling the target's guard relay selection.

Watch

Extended reading notes

Core claim

The paper's central claim is that Monero's Tor integration creates a deanonymization pipeline through the interaction of three independently exploitable protocol behaviors: (1) hidden service nodes deterministically append their own onion address to peer-list responses, allowing role identification; (2) originated transactions are forwarded only to two hidden service proxy nodes whose block heights exceed a local threshold, allowing an adversary who occupies outbound connections and advertises falsified block heights to capture originated transactions; and (3) the absence of rate-limiting on certain Monero P2P messages allows timing-based watermark embedding that survives Tor's encryptedcell

Load-bearing premise

The watermarking experiments use a controlled configuration where the target node's sole Tor guard relay is the adversarial relay. In the real Tor network, the probability of an adversarial relay being selected as a target's guard is only 0.06-0.12 with 179 malicious machines, and the paper never demonstrates a complete end-to-end pipeline linking a real transaction to a real IP address in a single experiment.

Editorial extensions

If this is right

  • Monero developers should extend Dandelion++ stem-phase forwarding over hidden service connections so that transactions received from incoming Tor peers could be either originated or relayed, eliminating the distinction the attack exploits.
  • The attack surface identified here generalizes to any cryptocurrency that uses anonymity networks with role-dependent forwarding policies, suggesting that protocol-level privacy analysis must account for the interaction between application-layer forwarding rules and transport-layer anonymity guarantees.
  • Tor-based cryptocurrency integrations that assign different protocol roles to different connection types (e.g., block-sync peers vs. transaction-forwarding peers) inherently create metadata that can be exploited even when the transport layer is encrypted.
  • Rate-limiting of application-layer request messages in P2P protocols is a necessary defense against timing-covert-channel attacks, as the absence of such limits creates an encoding channel visible to Tor relays.
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

5 major / 7 minor

Summary. This paper presents ProxyMark, a three-stage framework for deanonymizing Monero transactions sent over Tor. The key observation is that Monero's Tor integration forwards originated transactions exclusively through two selected hidden-service proxy nodes before clearnet propagation, creating a protocol-level choke point. Stage 1 identifies whether a Tor peer is a hidden-service or client node by exploiting deterministic differences in Timed Sync Response peer lists. Stage 2 captures originated transactions by filling target peer lists with adversarial onion addresses (connection occupation) and advertising falsified block heights (proxy selection bias). Stage 3 links Tor-level identifiers to real IP addresses through traffic watermarking detected at a malicious Tor entry relay. Each stage is evaluated separately on testnet, mainnet, or controlled Tor deployments.

Significance. The paper identifies a genuine and previously unexplored protocol-level vulnerability in Monero's Tor integration: the asymmetric forwarding of originated transactions through hidden-service proxy nodes creates a distinguishable propagation path that does not exist in ordinary clearnet Monero or in Bitcoin-over-Tor. The role-identification technique (Section III-C) is elegant and exploits a deterministic protocol behavior, achieving 100% precision and recall in experiments. The proxy-selection-bias technique (Section III-D) is novel relative to prior Bitcoin-focused work and is validated on mainnet with a clear gain from 15.3% to 35.7% with one occupied connection (Table I). The role-specific watermarking design, including the handshake-free embedding variant for hidden-service targets, is a thoughtful adaptation of prior watermarking ideas to Monero's specific noise characteristics. The paper also provides concrete, protocol-level mitigation suggestions for each attack stage. These are substantive contributions to the cryptocurrency network-security literature.

major comments (5)
  1. The central claim in the abstract and contributions is that ProxyMark 'successfully deanonymizes transactions originating from Monero nodes over Tor.' However, no experiment composes even two of the three stages, let alone all three. Each stage is evaluated in a different environment (testnet for role identification in Section IV-B, controlled Tor deployment with 10× scaled adversary and reduced target capacities for connection occupation in Section IV-C.1, mainnet with a different target type for proxy bias in Section IV-C.2, and testnet over live Tor with the adversary as sole guard for watermarking in Section IV-D). The targets, scaling assumptions, and environments differ across all experiments. Using the paper's own numbers, the composed success probability for a hidden-service target with 179 malicious machines is approximately 0.12 (guard selection, Appendix E) × 0.357 (proxy bias
  2. with one occupied connection, Table I) × ~0.8 (connection occupation rate, Section IV-C.1) × 0.994 (watermark detection after 8 injections, Eq. 2) ≈ 3.4%. This is far from the 'successfully deanonymizing' framing in the abstract. The paper is transparent about the guard-selection bottleneck (Appendix E) and the scaling (Section IV-C.1), but the abstract and contributions section do not reflect these limitations. The authors should either (a) tone down the abstract and contributions to accurately reflect that this is a component-level feasibility demonstration with a quantified end-to-end success probability, or (b) provide at least one composed end-to-end experiment, even in a controlled setting, showing a transaction being linked to an IP address through the full pipeline.
  3. Section IV-D: The watermarking experiments assume 'the target node uses the adversarial relay as its sole guard relay.' While the paper acknowledges this isolates watermark detection from guard-placement probability and provides the guard-selection analysis in Appendix E, this assumption is load-bearing for the 100% precision / 93.8% recall results. In the real Tor network, the adversary must first be selected as one of the target's two guards (p_e = 0.12 with 179 machines), and then only half of circuits use the adversarial guard. The paper does present Eq. (2) for repeated injections, but this analysis applies only after guard selection has already occurred. The gap between the experimental setup and the real-world scenario should be discussed more prominently in the main text (not just Appendix E), and the precision/recall numbers should be contextualized as conditional on adversarial
  4. guard placement.
  5. Section IV-C.1: The connection occupation experiments use a 10× scaled adversary (500 addresses instead of 5,000) with reduced target graylist capacity (500 instead of 5,000) and whitelist capacity (100 instead of 1,000). The paper states this is due to 'resource and ethical constraints,' which is understandable. However, the scaling implications are not analyzed: with the full 5,000-address adversary and full-capacity target lists, the graylist-filling time and occupation dynamics may differ substantially. The paper should discuss whether the observed occupation rates (7–11 of 12 connections after restarts, 8–10 of 10 after periodic replacement) would hold, degrade, or improve under full-scale parameters, and whether the 20-node graylist-filling strategy (sufficient for 500-capacity graylists) scales linearly to 5,000-capacity graylists.
minor comments (7)
  1. The date 'April 15th, 2026' in Section I appears to be a future date; this should be corrected to the actual date of the market capitalization data.
  2. Table I: The theoretical probability for n=1 is listed as 16.7%, but the baseline rate is 15.3% (24/157). The denominator 157 is not a round number of epochs; the paper should clarify how many epochs were observed and why the denominators differ across n values (157, 115, 108, 59).
  3. Section III-D, proxy selection bias: the paper states the adversary advertises 'current network height plus a small offset (e.g., +5 blocks).' The sensitivity of the proxy-selection gain to this offset value is not analyzed. Would +1 or +10 yield different results? A brief discussion would strengthen the robustness claim.
  4. Figure references in Section IV-C.1 mention Figures 6 and 7, but these figures are labeled (a)/(b)/(c) without clear axis labels in the text description. Ensure figure axes and legends are self-contained.
  5. The paper references 'Monero v0.18.3.1' for target nodes. It would be useful to note whether the identified vulnerabilities have been reported to the Monero project and whether any fixes are planned or implemented.
  6. Section III-E, watermark embedding: the choice of n=5 for hidden service nodes and n=6 for client nodes in the initialization pattern is stated without justification. The paper should briefly explain why these specific values were chosen and whether detection is sensitive to them.
  7. The paper uses both 'deanonymization' and 'de-anonymization' (and 'deanonymising'/'de-anonymizing') inconsistently. Standardize throughout.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity found; derivation chain is self-contained protocol analysis → attack design → empirical validation.

full rationale

The paper's three-stage pipeline (role identification, transaction capture, watermark-based IP linking) is built on independent protocol-level observations about Monero's Tor integration, not on fitted parameters or self-citation chains. Stage 1 exploits a deterministic difference in Timed Sync Response peer lists (hidden service nodes append their own onion address; client nodes do not) — this is a protocol observation verified empirically, not a fit renamed as prediction. Stage 2's proxy-selection probability (Eq. 1) is a standard combinatorial calculation whose baseline experimental rates match theory within <2% deviation, confirming independence. Stage 3's watermarking builds on Gao et al. [8] (different authors) and embeds/detects identifiers through message-timing modulation; the detection results are not forced by construction. The paper does cite a prior workshop abstract [1] by overlapping authors, explicitly flagged as 'An abstract version was published in WWW'24 workshop,' but this is transparent preliminary-work citation, not a load-bearing self-citation that forces the central result. The composed-probability concern (~3.4% with 179 machines) is an evaluation-scope issue, not a circularity issue — the paper transparently reports guard-selection probabilities in Appendix E and does not hide the bottleneck. No step in the derivation chain reduces to its own inputs by definition or by fit.

Assumptions & free parameters 8 free parameters · 6 assumptions · 2 invented entities

See above.

free parameters (8)
  • Number of malicious hidden service onion addresses = 5000 (threat model) / 500 (experiments)
    Stated in threat model as 5,000; experiments use 500 due to resource constraints (10× scaling). Controls graylist saturation effectiveness.
  • Falsified block height offset = +5 blocks
    Section III-D: 'the advertised block height is set to the current network height plus a small offset (e.g., +5 blocks)'. Chosen ad hoc to exceed target's local height.
  • Timed Sync message frequency for bias = every 20 seconds
    Section III-D: increased from default once per minute to once every 20 seconds. Chosen to refresh falsified heights more frequently than benign peers.
  • Watermark window size = 6 seconds
    Section III-E: 'we use a 6-second window in our implementation'. Controls watermark encoding granularity.
  • Carrier message separation = 0.2 seconds
    Section III-E: 'carrier messages sent within the same window are separated by at least 0.2 seconds'. Reduces message aggregation at Tor client.
  • Initialization pattern message counts = n=5 (hidden service), n=6 (client)
    Section III-E: different values for hidden service vs client targets. Chosen to distinguish from circuit-establishment traffic.
  • Malicious relay bandwidth = 20 MB/s
    Appendix E: used in guard selection probability calculation. Stated as the bandwidth of each malicious relay.
  • Number of injection attempts for hidden service = k=8
    Section IV-D: derived from P(8)=99.4% formula, but the 93.8% recall and 1/2 guard probability are measured/assumed values feeding this calculation.
assumptions (6)
  • domain assumption Monero Tor nodes forward originated transactions exclusively to two outgoing hidden service proxy nodes before clearnet propagation
    Section II-D, Figure 2. This is the protocol behavior the paper's entire attack relies on. Verified by code analysis and mainnet observation.
  • domain assumption Monero Tor hidden service nodes always append their own onion address as the last entry in Timed Sync Response messages to outgoing hidden service peers
    Section II-E, Figure 3. Verified experimentally with 100% precision/recall on testnet.
  • domain assumption Monero does not validate block height information in Timed Sync messages from hidden service peers
    Section III-D. Enables proxy selection bias via falsified heights. Verified on mainnet.
  • domain assumption Monero does not rate-limit Timed Sync Request messages
    Section III-E. Enables watermark embedding via message timing. Used as carrier signal channel.
  • standard math Tor entry relays can observe source IP and cell timing but cannot decrypt cell contents
    Standard Tor threat model. Section III-A threat model explicitly states this.
  • domain assumption The adversary can operate 5,000 Monero Tor hidden service onion addresses
    Section III-A threat model. Experiments use 500 due to resource constraints.
invented entities (2)
  • Proxy nodes independent evidence
    purpose: Designate the two outgoing hidden service peers selected to forward originated transactions
    Not a new entity per se but a named role in Monero's existing protocol. The paper identifies and names this role; it is verified by protocol code analysis and mainnet behavior.
  • Handshake-free watermark embedding independent evidence
    purpose: Inject watermark signals into hidden service node traffic without completing Monero handshake, avoiding protocol noise
    Exploits Monero's 256KB pre-handshake transmission allowance. Verified experimentally with 100% precision on testnet.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Deanonymizing Monero Transactions in Tor Network." pith.science (2026). https://pith.science/paper/UEY2FHVO

@misc{pith2026260707062,
  author       = {Pith},
  title        = {Pith review of: Deanonymizing Monero Transactions in Tor Network},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UEY2FHVO}},
  note         = {Machine review of arXiv:2607.07062}
}
read the original abstract

Monero is a privacy-focused cryptocurrency that deploys the Dandelion++ protocol and incorporates anonymity networks (such as Tor and I2P) to prevent malicious attackers from linking transactions with their source IPs. In this paper, we demonstrate that Monero's integration of the Tor network introduces a fundamental vulnerability: a Monero Tor node's originated transactions are exclusively forwarded to two outgoing Tor hidden service nodes (proxy nodes) prior to clearnet propagation, enabling an adversary to capture originated transactions by occupying the target node's outgoing connections. Based on this observation, we propose \textit{ProxyMark}, a three-stage deanonymization framework for the Monero Tor network, comprising node role identification, originated transaction identification, and node location deanonymization. Through experiments on the live Tor network, Monero mainnet, and testnet, we empirically demonstrate the effectiveness of \textit{ProxyMark} in successfully deanonymizing transactions originating from Monero nodes over Tor.

Figures

Figures reproduced from arXiv: 2607.07062 by the authors.

Figure 1
Figure 1. Connection patterns of Monero nodes: (a) ordinary node; (b) Tor client connected only to public peers; (c) Tor client [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Propagation path for transactions originated by Monero [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Onion-address lists in Timed Sync Response messages. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Overall process of ProxyMark. behaviors in Timed Sync Response messages sent over hidden service outbound connections. Specifically, for a Monero Tor hidden service node, the last onion address in each periodic Timed Sync Response message is always identical and corre￾…
Figure 5
Figure 5. Figure 5: Method to locate a Monero Tor node. den service peers to be considered outdated and consequently excluded from proxy nodes selection for originated transaction forwarding. Moreover, Monero Tor nodes do not validate the block height information contained in Timed Sync m…
Figure 6
Figure 6. Figure 6: Experimental results of outgoing connection occupation after adversarial address filling. [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Experimental results of outgoing connection occupation during periodic connection replacement. [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: Tor circuit structures for Monero node communication [PITH_FULL_IMAGE:figures/full_fig_p014_8.png]
Figure 10
Figure 10. Figure 10: Probability that a Monero Tor node selects a malicious [PITH_FULL_IMAGE:figures/full_fig_p015_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

33 extracted references · 33 canonical work pages

  1. [1]

    Deanonymizing transactions originating from monero tor hidden service nodes,

    R. Shi, Y . Ge, L. Lan, Z. Peng, S. Lin, and L. Li, “Deanonymizing transactions originating from monero tor hidden service nodes,” in Companion Proceedings of the ACM Web Conference (WWW)), 2024, pp. 678–681

    work page 2024

  2. [2]

    [Online]

    (2024) Coinmarketcap. [Online]. Available: https://coinmarketcap.com

    work page 2024

  3. [3]

    An analysis of anonymity in bitcoin using p2p network traffic,

    P. Koshy, D. Koshy, and P. McDaniel, “An analysis of anonymity in bitcoin using p2p network traffic,” inFinancial Cryptography and Data Security: 18th International Conference, FC 2014, Christ Church, Barbados, March 3-7, 2014, Revised Selected Papers 18. Springer, 2014, pp. 469–485

    work page 2014

  4. [4]

    Deanonymisation of clients in bitcoin p2p network,

    A. Biryukov, D. Khovratovich, and I. Pustogarov, “Deanonymisation of clients in bitcoin p2p network,” inACM SIGSAC Conference on Computer and Communications Security (CCS), 2014, pp. 15–29

    work page 2014

  5. [5]

    Bitcoin over tor isn’t a good idea,

    A. Biryukov and I. Pustogarov, “Bitcoin over tor isn’t a good idea,” in IEEE Symposium on Security and Privacy (SP), 2015, pp. 122–134

    work page 2015

  6. [6]

    Remote{Side-Channel}attacks on anonymous transactions,

    F. Tram `er, D. Boneh, and K. Paterson, “Remote{Side-Channel}attacks on anonymous transactions,” in29th USENIX Security Symposium, 2020, pp. 2739–2756

    work page 2020

  7. [7]

    Perimeter: A network-layer attack on the anonymity of cryptocurrencies,

    M. Apostolaki, C. Maire, and L. Vanbever, “Perimeter: A network-layer attack on the anonymity of cryptocurrencies,” inFinancial Cryptography and Data Security (FC). Springer, 2021, pp. 147–166

    work page 2021

  8. [8]

    A two-stage deanonymization attack towards bitcoin hidden service nodes,

    Y . Gao, J. Shi, X. Wang, R. Shi, C. Zhao, and C. Li, “A two-stage deanonymization attack towards bitcoin hidden service nodes,” inIEEE 23rd Int Conf on High Performance Computing & Communications; 7th Int Conf on Data Science & Systems; 19th Int Conf on Smart City; 7th Int Conf on Dependability in Sensor, Cloud & Big Data Systems & Application (HPCC/DSS/...

    work page 2021

Show all 33 references
  1. [9]

    Deanonymiz- ing Bitcoin transactions via network traffic analysis with semi-supervised learning,

    S. Zhang, B. Han, C. Tian, R. Shi, L. Lan, and Q. Wang, “Deanonymiz- ing Bitcoin transactions via network traffic analysis with semi-supervised learning,”arXiv preprint arXiv:2603.17261, 2026

    2026

  2. [10]

    Dandelion++ lightweight cryptocurrency networking with formal anonymity guarantees,

    G. Fanti, S. B. Venkatakrishnan, S. Bakshi, B. Denby, S. Bhargava, A. Miller, and P. Viswanath, “Dandelion++ lightweight cryptocurrency networking with formal anonymity guarantees,”ACM on Measurement and Analysis of Computing Systems, vol. 2, no. 2, pp. 1–35, 2018

    2018

  3. [11]

    [Online]

    (2024) Anonymity networks with monero. [Online]. Available: https://github.com/monero-project/monero/blob/master/docs/ANONY MITY NETWORKS.md

    2024

  4. [12]

    Trawling for tor hidden services: Detection, measurement, deanonymization,

    A. Biryukov, I. Pustogarov, and R.-P. Weinmann, “Trawling for tor hidden services: Detection, measurement, deanonymization,” inIEEE Symposium on Security and Privacy (S&P). IEEE, 2013, pp. 80–94

    2013

  5. [13]

    Toward a comprehensive insight into the eclipse attacks of tor hidden services,

    Q. Tan, Y . Gao, J. Shi, X. Wang, B. Fang, and Z. Tian, “Toward a comprehensive insight into the eclipse attacks of tor hidden services,” IEEE Internet of Things Journal, vol. 6, no. 2, pp. 1584–1593, 2018

    2018

  6. [14]

    Hsdirsniper: A new attack exploiting vulnerabilities in tor’s hidden service directories,

    Q. Zhang, Z. Teng, X. Wang, Y . Gao, Q. Liu, and J. Shi, “Hsdirsniper: A new attack exploiting vulnerabilities in tor’s hidden service directories,” inThe ACM Web Conference (WWW), 2024, pp. 1812–1823

    2024

  7. [15]

    [Online]

    (2022) We’re trying out guard-n-primary-guards-to-use=2. [Online]. Available: https://forum.torproject.org/t/tor-relays-were-trying-out-gua rd-n-primary-guards-to-use-2/3790

    2022

  8. [16]

    [Online]

    (2024) Numentryguards. [Online]. Available: https://gitlab.torproject.or g/tpo/core/tor/-/blob/HEAD/doc/man/tor.1.txt

    2024

  9. [17]

    [Online]

    (2011) Black ops of tcp/ip 2011. [Online]. Available: https: //dankaminsky.com/2011/08/05/bo2k11/

    2011

  10. [18]

    Deanonymization and linkability of cryptocurrency transactions based on network analysis,

    A. Biryukov and S. Tikhomirov, “Deanonymization and linkability of cryptocurrency transactions based on network analysis,” inIEEE European symposium on security and privacy (EuroS&P). IEEE, 2019, pp. 172–184

    2019

  11. [19]

    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,” in24th USENIX Security Symposium, 2015, pp. 129–144

    2015

  12. [20]

    Eclipse attacks on monero’s peer-to-peer network

    R. Shi, Z. Peng, L. Lan, Y . Ge, P. Liu, Q. Wang, and J. Wang, “Eclipse attacks on monero’s peer-to-peer network.” inNetwork and Distributed System Security (NDSS) Symposium, 2025

    2025

  13. [21]

    Deanonymiz- ing ethereum users behind third-party rpc services,

    S. Wang, M. Yang, W. Dai, Y . Liu, Y . Zhang, and X. Fu, “Deanonymiz- ing ethereum users behind third-party rpc services,” inIEEE Conference on Computer Communications (INFOCOM). IEEE, 2024, pp. 1701– 1710

    2024

  14. [22]

    Time tells all: Deanonymization of blockchain rpc users with zero transaction fee,

    S. Wang, M. Yang, Y . Liu, Y . Zhang, S. Zhang, Z. Ling, J. Cao, and X. Fu, “Time tells all: Deanonymization of blockchain rpc users with zero transaction fee,” inACM SIGSAC Conference on Computer and Communications Security (AsiaCCS), 2025, pp. 3490–3504

    2025

  15. [23]

    Deanonymizing ethereum validators: The{P2P}network has a privacy issue,

    L. Heimbach, Y . V onlanthen, J. Villacis, L. Kiffer, and R. Wattenhofer, “Deanonymizing ethereum validators: The{P2P}network has a privacy issue,” in34th USENIX Security Symposium, 2025, pp. 1319–1338

    2025

  16. [24]

    On the anonymity of peer-to- peer network anonymity schemes used by cryptocurrencies,

    P. Kumar Sharma, D. Gosain, and C. Diaz, “On the anonymity of peer-to- peer network anonymity schemes used by cryptocurrencies,” inNetwork and Distributed System Security (NDSS) Symposium. Internet Society, 2023

    2023

  17. [25]

    Ethereum eclipse attacks,

    K. W ¨ust and A. Gervais, “Ethereum eclipse attacks,” ETH Zurich, Tech. Rep., 2016

    2016

  18. [26]

    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,”Cryptology ePrint Archive, 2018

    2018

  19. [27]

    A stealthier partitioning attack against bitcoin peer-to-peer network,

    M. Tran, I. Choi, G. J. Moon, A. V . Vu, and M. S. Kang, “A stealthier partitioning attack against bitcoin peer-to-peer network,” in IEEE Symposium on Security and Privacy (SP), 2020, pp. 894–909

    2020

  20. [28]

    Three birds with one stone: Efficient partitioning attacks on interdependent cryptocurrency networks,

    M. Saad and D. Mohaisen, “Three birds with one stone: Efficient partitioning attacks on interdependent cryptocurrency networks,” in IEEE Symposium on Security and Privacy (SP), 2023, pp. 111–125

    2023

  21. [29]

    Partitioning ethereum without eclipsing it

    H. Heo, S. Woo, T. Yoon, M. S. Kang, and S. Shin, “Partitioning ethereum without eclipsing it.” inNetwork and Distributed System Security (NDSS) Symposium, 2023

    2023

  22. [30]

    Bijack: Break- ing bitcoin network with tcp vulnerabilities,

    S. Li, S. Shi, Y . Xiao, C. Zhang, Y . T. Hou, and W. Lou, “Bijack: Break- ing bitcoin network with tcp vulnerabilities,” inEuropean Symposium on Research in Computer Security. Springer, 2023, pp. 306–326

    2023

  23. [31]

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

    R. Shi, Y . Liang, Z. Guo, Q. Wang, L. Lan, C. Wang, and Z. Zheng, “Eclipse attacks on ethereum’s peer-to-peer network,” inThe ACM Web Conference (WWW), 2026, pp. 2740–2751. 14

    2026

  24. [32]

    Friend or foe? identi- fying anomalous peers in moneros p2p network,

    Y . Kopyciok, S. Schmid, and F. Victor, “Friend or foe? identi- fying anomalous peers in moneros p2p network,”arXiv preprint arXiv:2509.10214, 2025

    2025 arXiv

  25. [33]

    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,” inFinancial Cryptography and Data Security (FC). Springer, 2020, pp. 578–594. APPENDIXA MONERONODEINITIALIZATION This appendix supplies the bootstrap details referenced in Sect...

    2020

Pith tools

Reviewed July 9, 2026 · model on record in the stance chip above.