Your Bitcoin node speaks to peers over a transport you choose. Clearnet is fast but exposes your IP; Tor wraps traffic in onion routing; I2P (native in Bitcoin Core since v22.0) uses garlic-routed tunnels. None is universally best. The resilient default is running all three so no single network can isolate, censor, or eclipse you.
Every block and transaction your node relays travels over a network transport. That transport decides who can see your IP address, whether a censor can cut you off, and how hard it is for an adversary to surround your node with their own peers. This guide walks the hardware-fluent self-hoster through the three real options — clearnet, Tor, and I2P — with the actual bitcoin.conf directives, the honest trade-offs, and a decision framework grounded in the Bitcoin Core documentation. It stands on the shoulders of the Tor Project, the Invisible Internet Project (I2P), and the Bitcoin Core contributors who wired these networks into the reference client.
The three transports at a glance
Before the config, here is the shape of the decision. Treat this as a reference, not a verdict — the right answer depends on your threat model and your region.
| Property | Clearnet (IPv4/IPv6) | Tor (v3 onion) | I2P |
|---|---|---|---|
| Hides your node’s IP from peers | No (VPN only shifts trust to the VPN) | Yes | Yes |
| Bitcoin Core support | Always | Long-standing (v3 onion) | Native since v22.0 |
| Inbound reachability behind NAT | Needs port forwarding | Automatic onion service | Automatic via SAM |
| Relative block/tx latency | Lowest | Higher (3-hop circuits) | Higher (tunnel-based) |
| Peer pool size | Largest | Large | Smaller (newer) |
| Censorship resistance | Low (ISP/region can block) | High (bridges defeat blocks) | High (no fixed entry list) |
| Trusted third party | VPN, if used | None | None |
Clearnet: fast, simple, and fully exposed
Clearnet is plain IPv4/IPv6. It is the default, it has the largest and most diverse peer set, and it propagates blocks with the lowest latency because there are no anonymity hops in the path. The cost is obvious: every peer you connect to learns your real IP address, and so does your ISP, which can see that you run a Bitcoin node and can throttle or block the traffic in censored regions. Address-level surveillance can also tie that IP to transactions you originate.
A VPN is a partial, not a complete, answer. It hides your IP from peers and your ISP, but it does not make anonymity trustless — the VPN operator sees all of your traffic and the timing of it, becoming a single point you must trust and a single point an adversary can subpoena or block. A VPN also gives you no inbound reachability without explicit port forwarding, and many providers’ address ranges are themselves blocked or flagged. We name no vendors here; the structural point is what matters. Tor and I2P give you network-level anonymity without handing a third party that visibility. For background on how peer-to-peer reachability and validation underpin sovereignty, see what a full node actually does.
Tor: onion services for your node
Tor (The Onion Router) sends your traffic through a three-relay circuit so no single relay knows both who you are and what you are talking to. Modern Bitcoin Core uses v3 onion services exclusively; the deprecated v2 scheme is gone. Two distinct mechanisms are at play, and understanding the split is what makes Tor “click”:
- Outbound connections are routed through Tor’s SOCKS proxy, set with
-proxy(default127.0.0.1:9050). This also lets your node reach.onionpeers. - Inbound reachability is provided by an ephemeral v3 onion service that Bitcoin Core creates automatically by talking to Tor’s control port (
-torcontrol, default127.0.0.1:9051). This is governed by-listenonion(default1when listening is enabled).
Configuring the Tor daemon
For Bitcoin Core to auto-create its onion service, the local Tor daemon must expose its control port and let the bitcoind user authenticate. In your torrc:
ControlPort 9051CookieAuthentication 1CookieAuthFileGroupReadable 1
Then add the user running bitcoind to Tor’s group (commonly debian-tor on Debian/Ubuntu) so it can read the cookie-authentication file. Cookie auth is the recommended path; alternatively you can use a hashed control password and pass the clear-text form to bitcoind with -torpassword.
The bitcoin.conf side
A minimal Tor configuration that keeps clearnet outbound while accepting inbound over Tor looks like this:
proxy=127.0.0.1:9050listen=1listenonion=1torcontrol=127.0.0.1:9051debug=tor
If you want your node to reach peers only over Tor, add onlynet=onion. Be deliberate: a Tor-only node is convenient and private, but as Bitcoin Core developers note, it is more exposed to Sybil pressure because .onion addresses are free to mint, so an attacker can cheaply flood your outbound slots. That is the central argument for the multi-network setup later in this guide.
Tor bridges for censored regions
If your ISP or government blocks access to the public Tor network itself, configure bridges — these are unlisted entry relays, often combined with a pluggable transport that disguises the traffic. This is a Tor-daemon setting, not a bitcoin.conf setting; Bitcoin Core simply rides whatever circuits Tor builds. In torrc you would set UseBridges 1, declare a transport such as obfs4 or snowflake, and add the Bridge line(s) you obtained from the Tor Project. Once Tor connects through a bridge, your node’s onion routing works as normal. For regions where Tor is heavily targeted, pairing Tor with I2P is a pragmatic hedge.
I2P: native since Bitcoin Core 22.0
I2P (the Invisible Internet Project) is a separate anonymity network with a different design: garlic routing over short-lived, unidirectional tunnels, with no fixed list of entry guards. Where Tor was built to reach the clearnet web anonymously, I2P was built as a self-contained network for hidden services talking to each other — which fits Bitcoin’s peer-to-peer mesh well. Native support landed in Bitcoin Core v22.0, contributed by the Core developers who integrated the SAM bridge.
How i2psam works
Bitcoin Core speaks to a running I2P router through the SAM v3 bridge (Simple Anonymous Messaging), which listens on TCP port 7656 by default. Through SAM, your node creates an I2P destination — a long cryptographic identity — addressable by its human-readable .b32.i2p hostname. You will need an I2P router running locally: the Java reference router (I2P) or the C++ implementation (i2pd) both expose the SAM API once enabled.
The relevant Bitcoin Core options are:
i2psam=127.0.0.1:7656— the SAM proxy used to reach I2P peers and accept I2P connections (default: none).i2pacceptincoming=1— whether to accept inbound I2P connections (default:1; ignored ifi2psamis unset).onlynet=i2p— restrict automatic outbound connections to I2P only (use with care, see below).debug=i2p— verbose I2P logging while you confirm tunnels build.
Transient versus persistent destinations
The i2pacceptincoming flag carries a real privacy trade-off. With it enabled (the default), Bitcoin Core uses a persistent I2P address stored on disk, which is reachable for inbound peers and reuses tunnels for lower setup latency. Set it to 0 and your node uses a fresh transient address for outbound connections, “making it harder to discriminate, fingerprint or analyze it” — at the cost of inbound reachability. Note also that I2P’s peer pool is smaller and newer than Tor’s; running I2P alone can leave you more susceptible to Sybil pressure, which is, again, the case for combining networks rather than picking one.
The real trade-offs
Block-propagation latency
Anonymity is not free in milliseconds. Tor circuits add three relay hops; I2P routes through layered tunnels. Both increase the time for your node to learn about new blocks and to push your own transactions out, compared with a direct clearnet link. For a validating home node this rarely matters — you are not racing to template blocks. It matters more if you are doing latency-sensitive work. The practical mitigation is to keep at least one fast path: run clearnet alongside Tor and I2P so block relay stays close to the chain tip while your inbound peers and transaction origin remain shielded.
Eclipse and Sybil surface
An eclipse attack succeeds when an adversary controls all of your node’s connections, feeding you a false view of the chain. Bitcoin Core hardens against this in several ways: block-relay-only anchor connections that persist across restarts (since v0.21), an address manager designed to resist flooding, and — most relevant here — network diversity. A node reachable on only one anonymity network is easier to surround, because addresses on that network are cheap to create. A node spanning clearnet, Tor, and I2P forces an attacker to dominate three very different address spaces at once. Nodes in this configuration act as bridge nodes that, per the Core docs, “increase the cost and complexity of launching eclipse and partition attacks” for the whole network.
Wallet leaks versus node leaks
This is the trap that quietly undoes careful node privacy. Routing your node over Tor or I2P protects block and transaction relay at the network layer. It does nothing for your wallet if that wallet talks to someone else’s infrastructure. If your wallet software queries a public Electrum or block-explorer server, that server learns your addresses and the IP they came from; broadcasting through a third-party API leaks the transaction’s origin the same way. The fix is to point your wallet at your own node — and ideally reach it over Tor too. Node-layer and wallet-layer privacy are separate; you need both for a complete picture.
Why running all three is the resilient default
The argument throughout this guide converges on one recommendation: do not choose one network — run clearnet, Tor, and I2P together. This stopped being a manual chore in Bitcoin Core v26.0, which made nodes with multiple reachable networks actively maintain at least one outbound connection to each enabled network. As the release notes put it, this “improves individual resistance to eclipse attacks and network level resistance to partition attacks,” and users “no longer need to perform active measures” to stay connected across networks.
The combined recipe is to enable all transports and simply not set onlynet (leaving Core free to reach every reachable network). A representative bitcoin.conf:
listen=1proxy=127.0.0.1:9050listenonion=1torcontrol=127.0.0.1:9051i2psam=127.0.0.1:7656i2pacceptincoming=1
With this, outbound traffic that can use Tor will, your node advertises both an onion and an I2P address for inbound peers, clearnet keeps latency low, and v26+ keeps a foot in each network for you. If you want to hide your clearnet IP from outbound peers while still enjoying the speed of local validation, you can drop the bare clearnet listener and lean on Tor/I2P for connectivity — the point is that you are spanning networks, not betting on one. Most node appliances make this turnkey: projects like Umbrel and umbrelOS bundle a Tor daemon, and the broader self-hosting movement covered in our sovereign computing primer assumes anonymity transport as a baseline.
A short decision guide
Map the config to your situation rather than copying blindly:
- Home validator, no special threat: all three networks on, no
onlynet. Maximum resilience for minimal effort on v26+. - Privacy-first, willing to trade latency: Tor + I2P, drop the clearnet listener; accept inbound over onion and
.b32.i2p. - Censored region: Tor with bridges (obfs4/snowflake in
torrc) plus I2P as a parallel path the same censor may not block. - Maximum unlinkability for outbound: set
i2pacceptincoming=0for transient I2P addresses, accept the reachability cost.
Network-layer anonymity is one strand of self-sovereignty, not the whole rope. The same instinct that makes you run your own node — refusing to trust intermediaries — extends to censorship-resistant transports beyond the internet itself, like the mesh approach in our Reticulum network guide, and to the wider toolkit in the sovereignty hub. Run your own node, route it over networks no single party controls, and verify everything yourself with the references in our field manual.
Frequently asked questions
Does Tor or I2P slow down my Bitcoin node?
Yes, modestly. Both add relay hops, so blocks and transactions propagate with more latency than over clearnet. For initial block download and routine validation this is rarely noticeable. If you want low latency and privacy at once, run clearnet alongside Tor and I2P so a fast path stays available while inbound peers and transaction origin remain shielded.
Which Bitcoin Core version do I need for I2P?
Native I2P support arrived in Bitcoin Core v22.0 via the SAM v3 bridge. You also need a local I2P router (the Java I2P router or i2pd) with SAM enabled, listening on the default port 7656. Set i2psam=127.0.0.1:7656 in bitcoin.conf to connect.
Is a VPN a substitute for running my node over Tor?
No. A VPN hides your IP from peers but moves trust to the VPN operator, who sees all your traffic and timing, and it gives no inbound reachability without port forwarding. Tor and I2P provide anonymity without a trusted intermediary. If you use a VPN, treat it as a complement, not a replacement.
Why run all three networks instead of just Tor?
Because addresses on a single anonymity network are cheap to create, a one-network node is easier to Sybil and eclipse. Spanning clearnet, Tor, and I2P forces an attacker to dominate three address spaces at once. Bitcoin Core v26.0 even keeps at least one outbound connection to each enabled network automatically.
Will Tor or I2P keep my wallet transactions private?
Only at the node’s network layer. If your wallet queries a public Electrum or block-explorer server, that server still sees your addresses and IP. Point your wallet at your own node — ideally over Tor — so both the node layer and the wallet layer are covered.
Can I still connect if my country blocks the Tor network?
Yes. Configure Tor bridges with a pluggable transport such as obfs4 or snowflake in your torrc (UseBridges 1 plus the bridge lines). Bitcoin Core then rides those disguised circuits transparently. Running I2P in parallel adds a second path a censor may not be blocking.
