Tor can reduce the exposure of a Litecoin node's network address. MWEB addresses a different problem: disclosure of transaction information on the ledger. Combining them does not create a guarantee of anonymity.
This guide describes configuration choices against Litecoin Core v0.21.5.8 documentation, reviewed 18 September 2026. The examples are configuration references, not a claim that every operating-system package has been tested. Keep a recoverable wallet backup before changing a production setup.
Start with a threat model
| Observer | What Tor may reduce | What remains outside that protection |
|---|---|---|
| Remote peer | Direct exposure of your public IP on proxied connections | Application behavior and timing clues |
| Local network operator | Visibility of the final destination inside Tor | Visibility that Tor is being used, traffic volume |
| Blockchain analyst | Tor alone does not hide transparent ledger amounts | Address reuse, change heuristics, public transfers |
| Exchange or counterparty | Network routing does not erase account records | Identity checks, invoices, deposit records |
| Malware on your device | No dependable protection from a compromised endpoint | Keys, screen contents and transaction manipulation |
A sufficiently capable observer can correlate traffic without breaking encryption. Tor's own security explanation explicitly discusses remaining attacks. Tor Project.
Choose the connection profile
Onion-only outbound: connect to onion peers through Tor. No exit relay is used to reach an onion service. Proxied clearnet: reach ordinary internet peers through a Tor exit. The destination sees the exit address, and its own service is still on the public internet. Do not describe both modes with the same diagram. Onion-service properties.
An onion connection joins client and service circuits at a rendezvous point. It is not “three relays outbound and three relays on the return trip.” Entry guards are deliberately persistent rather than freshly randomized on every connection. Onion architecture, guard design.
Find the actual configuration file
Default data directories are ~/.litecoin on Linux, %APPDATA%\Litecoin on Windows and ~/Library/Application Support/Litecoin on macOS. A custom -datadir changes this. Edit the litecoin.conf used by the actual process, not an unrelated copy. Core data-directory implementation.
The examples assume a separately running Tor SOCKS service at 127.0.0.1:9050. Verify that port locally; Tor Browser commonly uses 9150. Never expose the SOCKS or control listener publicly for this setup.
A minimal outbound-only example
proxy=127.0.0.1:9050
onlynet=onion
listen=0
discover=0
upnp=0
Here onlynet limits outbound connections and listen=0 disables inbound listening. For clearnet peers through the same proxy, omit onlynet=onion; do not replace proxy with onion, which has a narrower purpose. The earlier guide disabled peer discovery without explaining recovery from zero peers. Diagnose discovery before adding more restrictions. Core Tor options.
Do not interpret a running process as proof of connectivity. Start with a small, non-sensitive test operation and inspect the network state. If a distribution overrides configuration through service arguments, those arguments must also be reviewed.
Optional inbound onion service
Incoming connectivity is optional. For a manual mainnet onion service, the following mapping uses an explicit loopback port on both sides.
Tor's torrc:
HiddenServiceDir /var/lib/tor/litecoin-service/
HiddenServicePort 9333 127.0.0.1:9333
Litecoin configuration, in addition to the proxy and onion-only options above, replacing listen=0:
listen=1
listenonion=0
bind=127.0.0.1:9333
externalip=YOUR_OWN_V3_ADDRESS.onion
Replace the placeholder with the hostname generated by your Tor service; do not use another operator's address. The alternative is Core's automatic onion-service creation with correctly authenticated Tor Control access. Choose one method and follow its permissions model. Avoid combining unrelated fragments from both methods. Core Tor setup.
The P2P service is not the wallet RPC interface. Do not publish RPC credentials or map the RPC port into the onion service. Keep administrative access separate from peer connectivity.
Verify behavior and diagnose failures
litecoin-cli getnetworkinfo
litecoin-cli getpeerinfo
litecoin-cli getblockchaininfo
Check reported proxy settings, active peers, synchronization progress and any warnings. For inbound operation, check the advertised local address and arrange a connection test from an independent Tor-enabled node. Configuration inspection alone cannot prove reachability.
| Symptom | First checks |
|---|---|
| No peers | Tor process, SOCKS port, peer discovery, system clock, logs |
| Proxy connection refused | Wrong port, service stopped, namespace/container mismatch |
| No advertised onion address | Manual externalip missing, or automatic control authentication failed |
| Sync does not advance | Peer availability, disk space, chain validation messages |
| Unexpected direct connection | Startup arguments, additional config files, other wallet processes |
Record versions and the exact error before changing anything. Do not make the node publicly reachable as a shortcut to diagnosing onion connectivity.
Privacy and performance limits
Fresh addresses reduce direct address reuse but do not defeat every clustering technique. MWEB does not erase information already disclosed to an exchange or customer. Syncing directly first can reveal that the same host operated a Litecoin node before it switched to Tor.
Latency and initial synchronization depend on routes, peers, storage and CPU. The former fixed “2–5 days” expectation was not backed by a benchmark. Measure your own setup and report elapsed time, hardware and software versions together.
Frequently asked questions
Is Tor plus MWEB equivalent to perfect anonymity?
No. Endpoint compromise, account records and traffic correlation remain relevant. Neither system makes operational mistakes disappear.
Do I need an inbound onion address to send payments?
No. Outbound peer connections can relay transactions. Inbound service configuration is a separate operational choice.
Can an explorer verify an MWEB amount?
Not an internal confidential amount. Use a compatible receiving wallet and the merchant verification workflow.
