JSON-RPC over Tor
Running a remote Bitcoin Core node's RPC interface behind Tor, adding anonymity and censorship resistance to node control.
JSON-RPC over Tor is the practice of exposing a Bitcoin Core node's RPC interface via a Tor hidden service (.onion address) instead of a clearnet IP. It lets you manage a remote node from anywhere without revealing the node's IP or your own.
Why this matters:
- Bitcoin Core's RPC port (8332) should never be exposed to the public internet. Anyone who reaches it with the right credentials can sign transactions, drain the wallet, or stop the node. Standard advice: bind to localhost only.
- Self-hosted nodes at home behind NAT typically can't be reached from a phone or laptop on the road unless you punch holes in the firewall (bad) or use a VPN (workable but extra layer to maintain).
- A hidden service flips this: bind RPC to a Tor v3 onion address. The address is unguessable, only reachable via Tor, and you don't need any firewall changes. The phone or laptop runs Tor and connects to the onion.
The setup is roughly:
- Install Tor on the same machine as Bitcoin Core.
- Configure a HiddenServiceDir and HiddenServicePort 8332 pointing at Bitcoin Core's RPC port.
- Leave Bitcoin Core's RPC on its default localhost binding. Tor connects to it from the same machine, so no
rpcbindorrpcallowipchange is needed. - Use the resulting
.onionURL with your wallet client (Sparrow, BlueWallet's connect-your-own-node feature, etc.).
What the onion adds:
- The onion address is only known to people you share it with.
- RPC auth (rpcauth in bitcoin.conf, or the cookie file) still applies on top of the onion.
- Tor adds anonymity: even an adversary who knows the .onion can't see your IP.
What it doesn't change: anyone who learns the address can reach the RPC port itself. Bitcoin Core's own docs say not to expose RPC to the internet at all, warning that even a Tor onion service could open it to attacks the interface was never hardened against, and they recommend a VPN or an SSH tunnel for remote access instead.
It's not the easiest setup, and it isn't the pattern Bitcoin Core recommends. Tools like Umbrel, Start9, and RaspiBlitz automate most of the configuration for operators who choose it anyway.
Key takeaways
- Bitcoin Core's own docs advise against exposing RPC this way and recommend a VPN or SSH tunnel instead
- Prevents direct IP exposure for remote RPC usage
- Requires extra configuration but significantly boosts privacy
Corrected
-
Was: The entry said security "stays solid" when a node's RPC is exposed through a Tor onion service, and called it the right pattern for remote access.
Now: Bitcoin Core's docs say not to expose RPC to the internet at all, warn that even an onion service could open it to attacks, and recommend a VPN or SSH tunnel. The setup steps were also corrected, since Tor needs no rpcbind or rpcallowip change. Details
Sources (1)
Related terms (5)
Published . Revised . One correction logged for this page.
Edit this page on GitHub