Monero Developers Address Tor and I2P Privacy Weakness in Node Synchronization

Monero developers have proposed delaying Tor and I2P peer connections while a node synchronizes. A node's unusual blockchain height could help an observer associate its anonymous connections with its public IP address. The same proposal addresses transactions that wait locally despite a successful wallet submission.

Issue #11663 raised the concern on November 2. PR #11671, opened November 3, remains open and unmerged as checked November 6, 2026. Neither source reports confirmed deanonymization or a failure of Monero's transaction cryptography.

Affected node configurations

The concern involves monerod, the node software, combining ordinary IP peers with Tor or I2P peer connections while behind the blockchain tip. The tip is the latest known block. It does not automatically apply to every wallet using Tor.

The released anonymity-network documentation distinguishes two settings. --tx-proxy connects to Tor or I2P hidden-service peers. --anonymous-inbound configures incoming anonymous peer connections through an existing hidden service. These connections exchange transactions, handshakes and periodic status messages, but do not download blocks.

The separate --proxy setting can route connections to ordinary IP peers through a proxy, including blockchain downloads. A wallet's connection to a remote node is another separate path. Our Tor and I2P comparison explains the networks themselves.

Why synchronization height can reveal a connection

A node's height records its progress through the blockchain. Handshakes and periodic peer messages disclose it, including over anonymity networks.

Many synchronized nodes share the same height. A node catching up may report a less common value. An observer seeing matching unusual heights and later progress across anonymous and IP connections could infer that they belong to one node. That requires visibility across those connections. A matching number alone does not establish an identity.

The proposed height documentation describes the correlation risk. It describes the risk without measuring how reliably an observer could make that match.

Delaying anonymous peers until synchronization

The peer-network patch would postpone outgoing Tor/I2P connections and refuse anonymous incoming connections until the first synchronization after each startup. Priority peers, seeds and mixed exclusive-peer lists also wait.

Nodes with only Tor/I2P addresses in --add-exclusive-node skip the wait. Those peers cannot supply blockchain blocks, and the node still exposes its height. With --no-sync, the usual wait lasts for the entire run unless that exception applies.

This protection covers peer networking, not a wallet-facing RPC hidden service. It does not reactivate if the node falls behind later. Peers reporting a low synchronization target can also end the wait early once compiled block hashes no longer constrain it. Connection timing can reveal when synchronization finishes. These documented limits prevent treating the proposal as complete protection against correlation.

Why accepted transactions can remain unsent

A second change concerns locally submitted transactions when exactly one anonymity network is configured but has no outgoing connection. The released network-selection code can call the sending routine without checking connectivity. The notification code can mark a transaction relayed before any successful send.

The transaction stays in the local pool of pending transactions. That marker delays retries, starting around five minutes and growing to four hours between attempts under the pool's retry rules.

The proposal checks outgoing connectivity first. With no suitable connection, a local transaction stays unrelayed and eligible for the pool's next check after connectivity returns. It does not automatically fall back to public IP peers. Transactions received from peers still forward to ordinary IP peers.

The explicit relay_tx RPC would report a relay failure. Ordinary send_raw_transaction can still return success after local acceptance without checking the relay result. The RPC source does not make wallet submission success a delivery receipt.

Patch status and what operators should do

The latest published release checked was v0.18.5.4, released October 17. Its source contains the pre-fix behavior. The earliest affected version remains unconfirmed.

The Monero Tor and I2P patch remains unmerged and unreleased despite approvals from Ap4sh and jpk68 for revision 6e88898. GitHub reports 16 successful checks and two Cross-Mac failures. The author calls those failures unrelated. Added unit tests cover connection gating and relay behavior, not a demonstrated correlation attack.

Keep to reviewed releases and check release notes for this change. Verify synchronization and outgoing anonymous peers before relying on transaction relay, then check payment confirmation. Restarting an unpatched node does not add the proposed gate. Wallet users should also distinguish their own node from the remote node they connect to.