TL;DR: Both TOR and VPN can be privacy-enhancing tools for your Bitcoin node, but they function differently:
TOR:
- A system where data packets are encrypted and passed through multiple relays, obscuring content and destination.
- Has two aspects: the TOR web browser for accessing the "dark web" and the encrypted network layer used for varied purposes, including Bitcoin node communication.
- Automatically supported by Bitcoin for node communication.
- Offers a globally accessible service but is slow due to multiple redirects and is vulnerable to DoS/DDoS attacks. Exit nodes might be monitored by third parties.
VPN:
- Creates an encrypted connection between your device and a remote server, masking your actual traffic origin.
- Some VPN providers might be regulated and could release user logs to third parties. They could also monitor your traffic.
- Direct home router VPNs, like Tailscale or OpenVPN, are safer as they do not route traffic through third-party servers.
Privacy attempts can make data seem more valuable to both authorities and malicious entities, making it more difficult to protect.
For most node operators, Tor is the better default: it distributes trust across multiple relays and lets the node accept inbound peers as a v3 onion service without a public IP address. A VPN trusts a single provider with the entire connection, which can help with bandwidth or jurisdiction but does not give the same anonymity. The two are complementary and can be combined when the threat model justifies the latency cost.
Both have their advantages and disadvantages, so the right choice depends on your use case. Their major characteristics, pros, and cons:
Tor: The Onion Router
The abbreviation Tor stands for the onion router, which relates to the fact that network packets sent via Tor are wrapped in encryption and sent to multiple relays, before they reach their destination. That means no single relay sees both who you are and where you are connecting; the middle relays cannot read the content or the destination at all, though the final exit relay does see the destination.
Tor is actually two separate things, both of which are built on the same foundation. One is the Tor web browser, which uses a unique naming scheme to identify pages or services on what's called the "dark web". Because this browser is of little relevance to Bitcoin, we will not go into detail here.
The other thing named Tor is an encrypted network layer, which also uses that same naming scheme to address nodes and services but can be used more universally than just for interactive web browsing. For instance, many Bitcoin node operators decide to base their node communication on TOR, and Bitcoin itself was programmed to enable that automatically. A Tor node creates a very long, unique identifier for every service it offers and communicates that to the Tor directory. Subsequently, this service (e.g., your Bitcoin node) can be reached via other Tor nodes from anywhere in the world, at least as long as the providers do not block Tor traffic.
One downside is that Tor is slow by design, because network packets are redirected several times in order to make the traffic hard to track. It is also subject to frequent DoS and DDoS attacks, which can seriously impact performance. It is also not as safe as one might think, because the number of exit nodes is small, and some of those may be run by spy services.
How a Tor Circuit Works
A standard Tor circuit uses at least three relays: an entry guard, a middle relay, and an exit relay. The entry guard knows the client's IP address but not the destination. The exit relay knows the destination but not the client's IP. No single relay sees both ends of the connection (Tor Project support).
Tor clients connect to a local SOCKS5 (SOCKet Secure 5) proxy, by default on port 9050, and applications such as Bitcoin Core route their network traffic through that proxy (Tor Project).
Onion Services (v3)
A v3 onion service is a destination inside the Tor network that has no public IPv4 address. Both the client and the server use a Tor circuit, so neither end learns the other's IP address. Tor v2 onion services were deprecated in 2021, and Bitcoin Core no longer accepts v2 addresses (Bitcoin Core tor.md).
Running a node behind a v3 onion service lets it accept inbound peers without a public IPv4 address, which solves the Carrier-Grade NAT (CGNAT) problem for home operators. Many home internet connections sit behind CGNAT, so the operator does not control a public IPv4 address and cannot accept inbound peers on the clearnet. A v3 onion service routes inbound peers through Tor instead, so the node contributes back to the network as a listening peer.
The Tor Project is also developing arti, an in-progress Rust reimplementation of the Tor client. arti does not yet change the threat-model picture for Bitcoin node operators.
VPN: Virtual Private Network
VPNs establish a cryptographically encrypted network layer between two endpoints. In many cases, this is between your own machine (or mobile phone) and a remote VPN server, often in another country. This makes it appear as if the traffic that actually comes from your machine, originates somewhere else. While this sounds very private, many of the VPN providers have been captured by local regulators and now have to release logs to the appropriate parties upon request. They might also peek into the data traffic and spy on you, because their own servers are an endpoint of the communication channel.
There are, however, VPNs that connect your mobile device back to your home router. Those are more secure to use because at least the traffic is not directly routed via some third party's servers. Software products like Tailscale or OpenVPN are examples of such VPNs (although they are not limited to that functionality).
The provider's jurisdiction matters. A provider in a jurisdiction that compels traffic logging, or that responds to subpoenas, can be required to hand over connection records. A provider that does not log, but is compelled to start logging after the fact, can only protect data that was not retained at the time of compulsion.
Threat Model: Distributed Trust vs. Single-Provider Trust
The structural difference between Tor and a VPN is where trust lives.
Tor distributes trust across at least three relays operated by different parties. An adversary that watches one relay learns one half of the circuit. An adversary that watches both ends of the circuit can correlate timing and deanonymize the user, but no individual relay is a single point of failure (Tor Project support).
A VPN concentrates trust in one provider. If the provider is honest, well-run, and outside compulsion reach, the VPN provides strong link-layer privacy against passive network observers. If any of those conditions fail, the VPN provides nothing the provider does not choose to provide.
For Bitcoin node operators concerned about linkage between their public IP and their on-chain activity, the distributed-trust model is the stronger default.
Performance Trade-Offs
Tor is slower than a clearnet connection. Each relay adds latency, and circuits run on volunteer hardware with variable bandwidth. A Tor-routed node syncs more slowly during initial block download and takes longer to propagate transactions.
VPNs run on production infrastructure with one hop of added latency, so a VPN-routed node is typically indistinguishable from a clearnet node in throughput.
For day-to-day node operation, both work. For initial block download on a fresh node, a VPN finishes faster.
Bitcoin-Node-Specific Considerations
Bitcoin Core supports both Tor and a VPN at the network layer. The configuration differs.
Tor With Bitcoin Core
Bitcoin Core uses Tor through a SOCKS5 proxy, by default listening on port 9050. The configuration uses -proxy for all outbound connections and -onion to specifically route .onion address connections. When -listen is also enabled, Bitcoin Core can connect to Tor's control socket and automatically create an ephemeral v3 onion service, which advertises the node as an inbound peer without any public IPv4 address (Bitcoin Core tor.md).
A VPN can also expose a node as a listening peer if the provider supports port forwarding, but the listening address becomes the VPN's IP, which is a stable identity tied to the operator's billing relationship.
i2p as an Additional Alternative
Bitcoin Core 22.0 added native i2p support, which uses the Simple Anonymous Messaging (SAM) proxy to route traffic through the i2p network alongside Tor (Bitcoin Core i2p.md). i2p is a separate overlay network with overlapping anonymity properties, fewer peers than Tor, and a different threat model.
A node can run on Tor, i2p, IPv4, and IPv6 at the same time. Operators concerned about eclipse-attack resistance run on multiple networks specifically so that no single network can isolate the node from the rest of the peer set.
For most operators, Tor alone is sufficient. i2p is useful as an addition rather than a replacement.
Roughly 23,000 reachable Bitcoin nodes were online as of May 2026 per bitnodes.io, with onion addresses making up a substantial minority of the total. Exact figures shift week to week.
Privacy Implications for Transaction Broadcast
When a wallet broadcasts a transaction, the transaction enters the mempool of the first peer it touches and then propagates. A network observer that watches the first peer can often link the transaction to the IP address that announced it.
A Tor-routed node breaks that link. The first peer sees an inbound connection from a Tor circuit, not from the operator's IP address. The observer cannot tie the announcement to the operator's network identity.
A VPN-routed node weakens the link but does not eliminate it. The first peer sees an inbound connection from the VPN's IP. An observer who can compel logs from the VPN, or who runs the VPN, can recover the original source. For an adversary without that compulsion power, a VPN gives meaningful protection.
Neither tool protects against on-chain linkage. Transactions on the blockchain are public, and address reuse, change-output heuristics, and clustering attacks operate independently of the network-layer protections.
Reliability
Tor circuits drop. Relays go offline, circuits expire after ten minutes by default, and the network itself occasionally hits performance degradations. Bitcoin Core handles reconnects without operator intervention, and a Tor-routed node remains stable in normal operation, but the network-layer noise is real.
A VPN is typically more stable than Tor. The provider runs production infrastructure with uptime guarantees, and a single tunnel either works or fails in obvious ways. Reconnects are clean.
For an unattended, headless node, either tool runs reliably enough for daily use. For a node that also runs latency-sensitive services such as a Lightning channel, the latency profile matters. See the Blockstream education on node security and privacy for layered protections that compound with Tor or a VPN.
Combining Tor and a VPN
A real configuration runs a VPN as the outer tunnel and Tor on top of it. Traffic flows from the client, into the VPN, then into a Tor circuit, and out an exit relay.
This combination adds belt-and-suspenders properties. The VPN hides from the entry guard that the user is connecting from a specific home IP, and Tor hides from the VPN that the user is talking to specific destinations. The cost is additional latency, an additional provider in the trust chain, and additional configuration.
Whether the combination improves anonymity depends on the VPN provider. If the VPN is honest, the combination is strictly better. If the VPN is compelled to log or is itself the adversary, the VPN learns that the user runs Tor traffic at specific times, which is sometimes the bit of information an adversary needs.
For Bitcoin node operators, the combination is rarely necessary. Tor alone is sufficient for the standard threat model.
When a VPN May Still Be Preferred
A VPN is the right tool in a few specific cases.
A node operator who needs a stable, advertisable IP address for an Electrum Server endpoint or a remote-procedure-call (RPC) endpoint accessible to a specific set of clients benefits from a VPN with port forwarding. Tor's v3 onion address is stable but not equivalent to an IPv4 endpoint for clients that do not speak Tor.
Operators in a jurisdiction that blocks or throttles Tor at the network layer may need a VPN to reach the broader internet at all. The VPN absorbs the censorship surface, and Tor can then run on top of the VPN if the operator wants both.
When hardware or a connection cannot tolerate Tor's latency, for example a Lightning node that needs fast block propagation, a VPN-routed clearnet connection is a reasonable choice that accepts the single-provider trust cost.
What Neither Tool Fixes
Network-layer privacy protects the link between the operator's IP and the operator's network identity. It does not protect the on-chain link between the operator's identity and the operator's coins.
Wallets that reuse addresses cluster those reuses together in the on-chain history, and common-input-ownership heuristics link any coins merged from different sources into the same input set. Once a transaction contains a known address, it stays tied to that address on the public ledger forever.
A Tor-routed node hides where the broadcast came from at the network layer. The transaction is still public on the blockchain. Operators concerned about on-chain privacy need wallet-level protections in addition to network-level protections. A self-custodial wallet such as the Blockstream app keeps the keys on the operator's own device, where address management is under the operator's control.
Ultimately, the more you try to hide your data, the more valuable third parties and bad actors perceive it to be.
Frequently Asked Questions
Is Tor better than a VPN for a Bitcoin node?
For most operators, yes. Tor's three-relay circuit distributes trust across multiple parties, lets the node accept inbound peers as a v3 onion service without a public IPv4 address, and breaks the link between the operator's IP and broadcast transactions. A VPN provides a single point of trust and a single IP.
Does Bitcoin Core support Tor natively?
Yes. Bitcoin Core 22.0 and later supports Tor v3 onion services natively. The default configuration assumes a Tor SOCKS5 proxy listening on port 9050, and Bitcoin Core can automatically create an ephemeral v3 onion service when -listen is enabled (Bitcoin Core tor.md).
What is a v3 onion service?
A v3 onion service is a Tor-internal destination address. The service runs behind a Tor circuit, so neither the client nor the server learns the other's IP address. v3 replaced v2 in 2021, and Bitcoin Core ignores v2 addresses.
Can a Bitcoin node run on Tor and i2p at the same time?
Yes. Bitcoin Core 22.0 added i2p support alongside Tor, IPv4, and IPv6. Running on multiple networks improves eclipse-attack resistance because no single network can isolate the node from the rest of the peer set.
Does using Tor make Bitcoin transactions private?
Tor hides the network-layer link between the operator's IP and the broadcast. It does not hide the transaction itself, which is public on the blockchain. On-chain privacy requires wallet-level protections such as address-reuse avoidance.
Should I combine Tor and a VPN?
For most node operators, no. Tor alone covers the standard threat model. A VPN-plus-Tor combination is useful when the operator needs to hide that they use Tor from their internet service provider, or when the operator is in a jurisdiction that throttles Tor.
Next Steps
A Bitcoin node configured to run as a Tor v3 onion service contributes back to the network as an inbound peer and protects the operator's network-layer privacy. For a step-by-step setup walkthrough, see how do I set up and run a Bitcoin node. For the broader picture of what a Bitcoin node is and how it fits into Bitcoin's verification model, start with the foundational education on nodes.