Running a Monero node over Tor or I2P

Ring signatures and one-time addresses protect what is on the chain. They do nothing for the IP address that hands a transaction to the network, and that address is what a peer, a spy node or a remote node sees first. Moneropedia's entry on remote nodes is direct about the last of these: node operators can link transactions to IP addresses. Its advice is to run your own node; where the address matters, that node can send over Tor or I2P.

Two options, two jobs

--proxy sends all of monerod's external traffic — syncing, peer connections, update checks — through a SOCKS proxy, but treats the proxy as the ordinary internet: it does not connect to hidden services through it. --tx-proxy is the anonymity-network mode. Once it is set, transactions the node creates are sent only to peers on Tor or I2P; if none is connected, the node logs an error and keeps the transaction rather than falling back to the public network.

The chain itself cannot be synced over hidden services: they carry handshakes, timed syncs and transaction broadcasts only. Running exclusively over hidden services is not supported either, because monerod relies on IPv4 to sync the blockchain and make sybil attacks more difficult. Syncing over Tor therefore means syncing from IPv4 peers through Tor with --proxy.

Four ways to run it

Beyond a plain clearnet node, the documentation gives four configurations, and what your internet provider sees in each.

Clearnet sync, transactions over Tor. monerod --tx-proxy tor,127.0.0.1:9050,10 syncs over the ordinary internet, so your provider sees a Monero node, but sends your transactions over Tor to up to ten hidden-service peers.

Everything over Tor, no hidden services. monerod --proxy 127.0.0.1:9050 --p2p-bind-ip 127.0.0.1. Your provider sees Tor, not monerod. The node accepts no incoming connections and does not reach hidden services.

Tor for syncing, hidden services for transactions. Add --tx-proxy tor,127.0.0.1:9050,10 --tx-proxy i2p,127.0.0.1:4447,10 to the line above. Your provider sees Tor and I2P, your transactions go to hidden services, and the node still accepts no incoming connections.

Publishing your own hidden services. With Tor and I2P set up to forward to the node, --anonymous-inbound youronionaddress.onion:18084,127.0.0.1:18084, and the same for a .b32.i2p address on another local port, lets other nodes send their transactions to yours. The port must be unique, not 18080, and the inbound address carries transactions only, never the chain.

Since v0.18.5.0, of 12 May 2026, the proxy in a --tx-proxy line can be SOCKS v5 with a user name and password, written socks5://user:pass@127.0.0.1:9050; the same release removed UPnP port mapping from monerod.

A wallet over Tor

A wallet on another machine talks to the node's RPC, which needs a hidden service of its own, separate from the P2P one; the documentation's Tor configuration puts it on port 18089. The wallet then connects with monero-wallet-cli --proxy 127.0.0.1:9050 --daemon-address youronionaddress.onion:18089. The proxy must match the address type: a Tor proxy will not reach an I2P address. An onion or b32.i2p address on its own authenticates and encrypts the connection from end to end.

Noise and padding

By default, a node sending over Tor or I2P hides its transactions in noise: fixed-size 3 KiB packets sent on two channels every 10 to 15 seconds whether or not there is a transaction to carry, so a watcher of the encrypted link cannot tell when one was sent. Adding disable_noise at the end of a --tx-proxy line turns it off; the Dandelion++ guide has what changes when it does. Two more options help: --pad-transactions pads relayed transactions to a multiple of 1024 bytes against traffic-volume analysis, and --hide-my-port stops the node advertising its port to peers.

Tor or I2P

I2P's own comparison page draws the difference. Tor builds bidirectional three-hop circuits and keeps its directory with nine directory authorities; I2P uses one-way tunnels, packet switching and garlic routing, with a distributed database kept by floodfill routers. Tor has millions of daily users against I2P's roughly 55,000 routers, by the comparison table I2P published for 2025. Monero's documentation weighs that for one attack in particular: against active bandwidth shaping I2P protects better, because its connections are not circuit-based, but it has a smaller set of users, so less cover traffic, and fewer academic reviews. monerod can use both at once.

What still leaks

The documentation lists four ways the machine behind an anonymity-network connection could still be identified.

Timestamps. The periodic timed-sync message carries the node's clock. A peer that sees the same slightly wrong time on a Tor connection and an IPv4 one could link the two. Keep the system clock accurate.

Intermittent syncing. A node started only to send a transaction and then stopped tells your provider when you transacted. Run monerod as often as you can.

Active bandwidth shaping. An attacker could shape traffic to find the source of a Tor or I2P connection. There is no strong mitigation; I2P resists it better.

The same stream used twice. If two transactions travel over the same hidden-service connection, its operator can conclude that they came from one source, and if the second spends change from the first, which ring member was real. monerod picks two outgoing connections every five minutes and change is locked for about 20 minutes, so connections usually change in between; the documentation still warns of a decent probability of reuse, because the number of outgoing connections is small.