{"id":"35f82825-0b14-4e95-b17b-b9d81ba2e5a8","arxiv_id":"2607.07062","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":8,"one_line_summary":"Monero Tor nodes forward originated transactions exclusively through two hidden-service proxy nodes, enabling an attacker who occupies those connections and runs a malicious Tor guard relay to link transactions to source IP addresses.","lead":"This paper shows that Monero's Tor integration leaks the source IP of transactions because originated transactions are forwarded through a small set of proxy nodes before reaching the clearnet, allowing an attacker to capture and watermark them. It matters because Monero is the leading privacy cryptocurrency, and if this attack works end-to-end, Tor alone does not protect Monero users from network-layer deanonymization.","discovery_kind":"unclear","skeptic_critique":{"model":"glm-5.2","headline":"Three stages evaluated in isolation across different environments (testnet, mainnet, controlled Tor) with different target types and scaling assumptions; composed success probability is ~3-4% with 179 machines, undercutting the abstract's 'successfully deanonymizing' language.","rationale":"The reader correctly identified the lack of end-to-end demonstration, the controlled guard configuration, and the 10× scaling as the key concerns. My analysis confirms this is the most load-bearing issue. I sharpen the concern in two ways: (1) the stages are not only uncomposed but tested in different environments with different target types and scaling assumptions, making composition assessment impossible even in principle; (2) the paper's own numbers yield a composed success probability of ~3.4% with 179 machines, which is quantitatively at odds with the 'successfully deanonymizing' language. However, the reader's CONDITIONAL verdict is appropriate. The protocol-level vulnerability analysis is sound and valuable — the observation that Monero forwards originated transactions exclusively through two proxy hidden service nodes is a genuine architectural weakness. The component-level experimental results are strong and the mitigations are well-reasoned. The paper makes a real contribution to understanding Monero's Tor integration vulnerabilities even without an end-to-end demonstration. The CONDITIONAL verdict captures the right balance: the insights are valuable but the headline claim overstates what was empirically demonstrated. The paper would benefit from either (a) an end-to-end testnet experiment or (b) tempering the abstract to say 'identifies and validates component-level vulnerabilities in Monero's Tor integration that could enable transaction deanonymization' rather than claiming successful deanonymization.","tokens_in":20901,"tokens_out":4378,"duration_ms":157854,"concrete_test":"Run the full ProxyMark pipeline end-to-end on the Monero testnet over the live Tor network with realistic parameters (5000 adversarial addresses, unscaled target graylist/whitelist capacities, adversary operating Tor relays with standard guard-selection probability). For each of ~50 originated transactions from a target node, measure whether the pipeline successfully links the transaction to the correct source IP. If the end-to-end success rate exceeds 10%, the abstract's claim is well-supported. If below 1%, the claim requires significant qualification to 'demonstrating component-level vulnerabilities that could enable deanonymization under favorable conditions.'","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim 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 tested in a different environment: role identification on testnet (Section IV-B), connection occupation in a controlled live Tor deployment with 10× scaled adversary and reduced target capacities (Section IV-C.1), proxy bias on Monero mainnet with a different target type (Section IV-C.2), and watermarking on testnet over live Tor with the adversary as the sole guard (Section IV-D). The targets differ across experiments (hidden service vs. client), the scaling assumptions differ (500 vs. 5000 addresses, reduced vs. full capacities), and the environments differ (testnet vs. mainnet vs. controlled deployment). Using the paper's own numbers, the composed success probability for a hidden service target with 179 malicious machines is approximately: P(guard selection) × P(proxy selection | 1 occupied connection) × P(connection occupation) × P(watermark detection | guard) ≈ 0.12 × 0.357 × 0.8 × 0.994 ≈ 3.4%. This is far from the 'successfully deanonymizing' framing. The paper is transparent about the guard-selection bottleneck (Appendix E) and acknowledges the scaling (Section IV-C.1), but the abstract and contributions section do not reflect these limitations. The component-level results are genuinely strong (100% precision for role ID and watermarking, 80%+ connection occupation), but the gap between component evidence and the integrated claim is the paper's most load-bearing weakness.","agreement_with_reader":"agree"},"referee_report":{"model":"glm-5.2","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.","tokens_in":21169,"tokens_out":1723,"duration_ms":153596,"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":[{"comment":"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","section":null},{"comment":"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.","section":null},{"comment":"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","section":null},{"comment":"guard placement.","section":null},{"comment":"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.","section":null}],"minor_comments":[{"comment":"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.","section":null},{"comment":"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).","section":null},{"comment":"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.","section":null},{"comment":"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.","section":null},{"comment":"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.","section":null},{"comment":"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.","section":null},{"comment":"The paper uses both 'deanonymization' and 'de-anonymization' (and 'deanonymising'/'de-anonymizing') inconsistently. Standardize throughout.","section":null}],"recommendation":"major_revision","confidential_remarks":"The component-level results are genuinely strong, and the protocol-level vulnerability analysis is sound and novel. The main issue is a framing mismatch: the abstract and contributions claim successful end-to-end deanonymization, but the experiments are component-level with composed success probabilities around 3-4% under realistic parameters. This is fixable by adjusting the framing to accurately represent the contribution as a feasibility demonstration with quantified end-to-end probabilities, rather than claiming successful deanonymization. The prior workshop abstract [1] is properly disclosed and the present paper substantially extends it. I would encourage the authors to at least attempt a composed end-to-end experiment in a controlled setting, as this would significantly strengthen the paper."},"author_rebuttal":null,"desk_editor":{"model":"glm-5.2","letter":"The core finding here is genuinely new: Monero's Tor integration forwards originated transactions exclusively through two hidden-service proxy nodes before clearnet propagation, which creates a capture point an adversary can exploit. The paper identifies three concrete protocol-level leaks — deterministic onion-address self-advertisement in Timed Sync Responses, proxy-only forwarding of originated transactions, and unvalidated block heights for proxy selection — and each is a real finding that Monero developers should take seriously. The component-level experiments are solid: 100% precision and recall on role identification, 80%+ connection occupation rates, and a 20-point boost in proxy selection from block-height falsification. The watermarking achieves 100% precision with ~93% recall under controlled conditions. The protocol analysis is careful and the mitigations are well-reasoned. Credit where it's due — this is real systems work on live networks, not a toy model. The soft spot is load-bearing: no experiment composes even two of the three stages, let alone all three. Each stage is tested in a different environment (testnet, mainnet, controlled Tor deployment) with different target types and a 10× scaled adversary. The watermarking experiments assume the adversarial relay is the target's sole guard, which the paper's own Appendix E admits has a 6–12% probability with 179 machines. Using their numbers, the composed end-to-end success rate is roughly 3–4%. That's a feasibility argument, not a demonstrated attack. The abstract's claim of 'successfully deanonymizing transactions' isn't supported by an integrated demonstration. The stress-test concern about composed probability is correct and lands squarely. The paper is transparent about these limitations in the body, but the framing in the abstract and contributions doesn't match. This is for security researchers and Monero protocol developers. The protocol-level insights have value independent of end-to-end feasibility, and the mitigations are actionable. It deserves a serious referee who can push the authors to either run an integrated experiment or recalibrate the claims.","headline":"Real protocol-level vulnerabilities in Monero-over-Tor, but no end-to-end demonstration — the abstract overstates what was shown.","tokens_in":21758,"tokens_out":474,"would_cite":true,"duration_ms":87444,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"glm-5.2","headline":"Monero's Tor shield leaks: transactions traced to source IPs","keywords":[],"falsifier":"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.","tokens_in":21141,"feed_emoji":"🧅","tokens_out":909,"duration_ms":132377,"temperature":0.7,"pith_summary":"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.","feed_headline":"Monero's Tor shield leaks: transactions traced to source IPs","feed_subtitle":"Protocol-level forwarding rules let adversaries capture originated transactions and link them to real IP addresses via traffic watermarking.","key_machinery":"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.","core_discovery":"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","pith_inferences":[],"forward_implications":["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."],"fun_headline_variants":["Monero over Tor: proxy nodes expose transaction origins","Three Monero protocol flaws enable Tor deanonymization","ProxyMark: watermarking Monero transactions through Tor","Monero's Tor forwarding rules leak source IPs","Hidden service proxy nodes enable Monero deanonymization"],"cache_read_input_tokens":0,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Monero over Tor: proxy nodes expose transaction origins","Three Monero protocol flaws enable Tor deanonymization","ProxyMark: watermarking Monero transactions through Tor","Monero's Tor forwarding rules leak source IPs","Hidden service proxy nodes enable Monero deanonymization","Monero Tor nodes deanonymized via traffic watermarking","Dandelion++ bypass: Monero source IPs exposed over Tor","Monero P2P leaks let adversaries trace Tor transactions","Capturing Monero transactions by occupying Tor outbounds","Monero Tor integration fails to hide transaction origins"]},"model":"glm-5.2","effort":"low","cost_usd":0.0,"raw_usage":{"total_tokens":656,"prompt_tokens":466,"completion_tokens":190,"prompt_tokens_details":null},"tokens_in":466,"tokens_out":190,"duration_ms":6745,"temperature":1.0,"reasoning_tokens":59,"cache_read_input_tokens":0,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-09T20:41:34.538631+00:00","model_set":{"reader":"glm-5.2"},"falsifier":"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.","supporting_citations":[],"review_version":1}