Monero / Security / Privacy
Monero Tor I2P Privacy: Developers Address Sync and Relay Issues
Monero developers are reviewing a patch for a potential Tor/I2P privacy leak and a transaction-relay failure. It remains open and unmerged.
What developers discovered
Monero developers are reviewing two changes to how monerod, the Monero node software, handles Tor and I2P connections. One limits information exposed while a node catches up with the blockchain. The other fixes a transaction-relay failure that can leave a payment waiting locally despite a successful wallet submission.
The height-correlation concern was raised in issue #11663. Pull request #11671 addresses both problems. As checked on November 4, 2026, it remains open and unmerged. The reviewed discussion identifies a potential privacy leak, without reporting confirmed exploitation. It does not describe a break in Monero’s transaction cryptography.
How Monero uses Tor and I2P
A node downloads and checks blockchain data, then exchanges information with other nodes, called peers. These two networks can help conceal the origin of transactions. Our comparison of Tor and I2P explains the two networks.
Monero’s --tx-proxy setting enables outgoing connections to their hidden services. --anonymous-inbound configures incoming peer connections through a separately configured hidden service. Before this patch, these connections can operate while the node is still synchronizing.
Those peer connections carry transactions, introductory handshakes and periodic status messages. They do not download blockchain blocks. Monero Tor synchronization through the separate --proxy option instead reaches ordinary IP peers through a proxy. That distinction matters when assessing Monero node privacy. See the project’s anonymity-network documentation.
Using Tor Browser also does not configure your wallet or node. Our Tor access guide explains that separation.
How the Monero Tor I2P privacy leak could work
A node’s height describes how far it has progressed through the blockchain. Peers learn it when they first connect and during regular status exchanges, including over anonymous connections.
Many fully synchronized nodes report the same height. A node partway through an initial download may have a much less common height. An observer could compare an anonymous connection with an ordinary internet connection. If both report the same unusual height and progress together, that could suggest they belong to one node. The anonymous connection could then be linked to an IP address.
Matching height alone does not identify a person. This possible attack requires observations across the relevant connections. The report does not establish how often such matching succeeds in practice. The proposed height documentation describes the exposure and its limits.
Why a transaction can wait without being sent
The Monero transaction relay bug affects transactions submitted to a node by a wallet or another local client. It occurs when exactly one anonymity network is configured and has no usable outgoing connection.
The old network-selection code calls the sending routine without first checking for that connection. The notification routine can mark the transaction as relayed before an actual send succeeds.
The transaction remains in the local pool, where the node holds pending transactions. It is not immediately deleted by this failure. But the incorrect marker delays retries. The wait starts around five minutes and grows to as much as four hours between attempts. Those limits come from the transaction-pool code.
A node can therefore log a broadcast failure while the wallet receives success. Acceptance by one node is not evidence that other nodes received the transaction, or that it has been confirmed in a block.
What the proposed patch changes
The peer-network changes postpone outgoing connections through either anonymity network and reject anonymous incoming connections until the first synchronization after each startup. Priority peers, seed peers and mixed exclusive-peer lists also respect that wait.
For local transactions, the patch checks outgoing anonymity-network availability even when only one such network is configured. With none available, the transaction stays unrelayed and eligible for the pool’s next relay check after connectivity returns. It does not automatically fall back to broadcasting that local transaction over ordinary IP connections.
The explicit relay_tx remote procedure call, an interface for requesting a retry, would report failure when relay cannot proceed. The ordinary send_raw_transaction submission path still returns success after accepting a valid transaction, without checking the relay result. The RPC changes do not make wallet submission success a delivery receipt.
What node operators should know
The proposed protection has limits. An exclusive-peer list tells the node to connect only to the listed peers. If it contains only Tor/I2P addresses, the node skips the wait because those peers cannot supply blockchain blocks. Its peers can still see the node’s height. With --no-sync, the normal wait lasts for the entire run unless that exemption applies.
The gate also does not reactivate if a running node falls behind later. An RPC hidden service, which wallets use separately from peer networking, can still expose height. Once a node passes its built-in block hashes, it can accept the highest height reported by its IP peers as its sync target. Peers that are behind, or claim to be, can therefore end the wait early. Connection timing can also reveal when synchronization finished.
The patch documentation recommends stopping the node before sleep or a prolonged disconnection, then restarting afterward. While the patch is pending, restarting alone does not add its synchronization gate. Check that your node has finished syncing and has outgoing peers before relying on relay. Check actual payment confirmation afterward. Wallet users can review our remote-node connection guide.
Patch status and remaining questions
The latest published release checked was v0.18.5.4. Source inspection found the relevant pre-fix behavior there and in v0.18.4.6. This confirms affected code paths in those versions, not a complete affected-version range.
Ap4sh and jpk68 approved revision 6e88898, but approval is not a merge or release. Its automated checks showed 16 successes and two Cross-Mac failures. The author described failures as unrelated. The new unit tests cover incoming connection gating, Tor dialing and exemption cases, and local relay without outgoing peers. They do not demonstrate a real-world correlation attack.
The earliest affected version remains unconfirmed. The reviewed PR has not shipped in an upstream release. Operators should check upstream merge and release status before treating an update as containing this patch.