Node operators should use an open-source client, such as Bitcoin Core, so that its code can be fully audited and verified to be secure.
Bitcoin's original peer-to-peer transport was unencrypted, so an internet service provider (ISP) could see that a node was running (BIP 324 v2 transport, on by default since Bitcoin Core 27.0, now encrypts traffic between v2-capable peers, as covered below). An ISP cannot alter an operator's transactions, because any change would require a new signature from the operator's private key.
To keep a node private, connect to the outside world over Tor (the onion router). A VPN (virtual private network) can also obscure a node's traffic, though many VPN providers keep logs and will hand them over to third parties upon request.
Most node distributions support and integrate Tor connectivity, which also makes it easier to reach a self-hosted node from the internet.
TL;DR: Securing and privately running a Bitcoin node means three things: protecting the machine and the wallet keys it holds, controlling how the node talks to the rest of the network, and protecting the operator's identity behind it. Tor v3 onion services, BIP (Bitcoin Improvement Proposal) 324 encrypted p2p transport, anchor peers, GPG (GNU Privacy Guard)-verified releases, and disciplined wallet encryption are the main levers.
What Bitcoin Node Privacy and Security Mean
Security and privacy for a Bitcoin node are distinct properties, and conflating them leads to weak configurations. Security covers confidentiality of any keys the node controls, integrity of the validated chain, and availability of the node when it is needed. Privacy covers two separate identities: the operator's identity (the IP (Internet Protocol) address and ISP record tied to the node) and the wallet's identity (which addresses, transactions, and balances belong to the operator).
Lightweight wallets that talk to third-party servers leak the wallet's address set to whoever runs those servers. A self-hosted full node validates blocks locally and queries no third party for balances, and an operator can cross-check any address against the node's own data using a self-hosted reference such as Blockstream's open-source Esplora explorer. The remaining work is keeping the operator's network identity from leaking and the keys safe.
Verify Every Release Before Installing
Bitcoin Core releases are signed by multiple maintainers, and the project publishes SHA256SUMS and SHA256SUMS.asc alongside every binary. Node operators should fetch both files, import the signing keys from github.com/bitcoin-core/guix.sigs, and run gpg --verify SHA256SUMS.asc SHA256SUMS before checking the binary's hash against the file. A binary that does not match a verified SHA256SUMS line should never be executed, regardless of where it was downloaded.
Operating system patching matters as much as Bitcoin Core patching. Outbound HTTPS for kernel security updates and a documented patch cadence (weekly for desktop builds, automated for headless installations) close a class of attacks that no Bitcoin-specific hardening will catch.
Encrypt the Wallet and Protect the Keys
Bitcoin Core's encryptwallet RPC (Remote Procedure Call) applies AES-256-CBC encryption to private keys stored in wallet.dat. Once a wallet is encrypted, the private keys remain locked until walletpassphrase unlocks them for a defined number of seconds. Operators should pick a high-entropy passphrase, store it in a password manager separate from the node, and never include it in shell history or scripts.
Descriptor wallets, the default in current Bitcoin Core, derive keys from a master secret. Bitcoin Core does not hand out a BIP 39 style recovery phrase, so the canonical restore path is a backup of the wallet file itself or an exported output descriptor: a corrupted wallet.dat is only recoverable from one of those, and neither can be reconstructed from a node's chain data. The same discipline applies whether the node holds the keys directly or serves an external wallet such as the Blockstream app, which reaches the node through an Electrum-protocol server, or Blockstream Jade, which pairs with companion wallet software rather than talking to the node directly.
Run a Bitcoin Node Over Tor v3
Tor v3 onion services give a Bitcoin node a network identity that does not expose its IP address. Tor v2 was deprecated by the Tor Project in 2021 and Bitcoin Core 22.0 removed support; only the 56-character v3 .onion format is accepted.
Bitcoin Core can configure a v3 onion service automatically when three conditions are met:
- listen=1 is set in bitcoin.conf
- -proxy=127.0.0.1:9050 routes outbound traffic through the Tor SOCKS port
- The Tor control port is reachable with either cookie authentication (the user running bitcoind has read access to Tor's auth cookie file) or password authentication via -torpassword
A minimal torrc for cookie authentication sets ControlPort 9051, CookieAuthentication 1, and CookieAuthFileGroupReadable 1. With these in place, Bitcoin Core creates an ephemeral onion service at startup and advertises it via addr messages so other Tor-enabled peers can reach the node.
Setting onlynet=onion restricts outbound connections to onion peers, which removes any direct clearnet exposure but also reduces the available peer pool. Most operators leave clearnet outbound enabled and only the inbound side hidden behind Tor.
See doc/tor.md for the full set of options, including -noonion, -bind=...=onion, and how to disable address advertising via -discover=0.
Add i2p and CJDNS for Network Diversity
Bitcoin Core 22.0 introduced support for the i2p anonymity network through the SAM (Simple Anonymous Messaging) bridge. Enabling it requires a local i2p router with SAM listening on its default port and a single Bitcoin Core option: -i2psam=127.0.0.1:7656. On first run, Bitcoin Core generates a persistent i2p address and stores it in i2p_private_key under the data directory.
The i2p network has fewer Bitcoin peers than Tor or clearnet, which means a node that runs i2p-only can struggle to find peers and risks Sybil exposure. The recommended setup combines i2p with Tor and clearnet so peer diversity is maintained even when one network is degraded. See doc/i2p.md.
Bitcoin Core 23.0 added CJDNS support via -cjdnsreachable. CJDNS is an encrypted IPv6 overlay using public-key cryptography for address allocation, with peers communicating in the fc00::/8 range. The Bitcoin CJDNS population is small, but operators who already run CJDNS for other reasons can advertise that reachability and pick up CJDNS peers without changing the rest of the node's networking. See doc/cjdns.md.
BIP 324 Encrypted p2p Transport
The original Bitcoin p2p protocol sent every message in plaintext. A passive observer between two peers, including an ISP or a state-level network operator, could read every announced transaction, every block, and every address gossip on the wire. BIP 324 introduces a v2 transport that adds opportunistic encryption to peer connections using ChaCha20-Poly1305.
BIP 324 is marked Deployed in the BIP repository and has been enabled by default since Bitcoin Core 27.0 (disable it with -v2transport=0). A v2-capable node negotiates encryption with peers that also support v2 and falls back to v1 with peers that do not, so network fragmentation is avoided during rollout.
Three properties matter for an operator. First, the encrypted bytestream is pseudorandom, which prevents trivial deep-packet-inspection censorship of Bitcoin traffic. Second, both peers derive a shared session ID that can be used for out-of-band authentication. Third, keys rekey every 224 messages, providing forward secrecy if a long-running session's keys are later compromised. BIP 324 does not authenticate peers by default; it raises the cost of passive surveillance without claiming to defeat active man-in-the-middle attacks.
Anchor Peers and Eclipse Attack Resistance
An eclipse attack happens when an attacker controls every connection a node has, isolating it from honest peers and feeding it whatever view of the chain the attacker wants. Heilman et al. described practical eclipse attacks against Bitcoin in 2015 (USENIX paper), and Bitcoin Core has hardened peer selection considerably since.
Two mitigations carry most of the weight. First, Bitcoin Core writes a small set of trusted long-running peers to an anchors file on shutdown and reconnects to them on restart, so an attacker cannot eclipse a node simply by occupying every outbound slot after a reboot. Second, mixing network types (clearnet, Tor, i2p, CJDNS) raises the attacker's required surface: eclipsing a node that has eight clearnet, two Tor, and one i2p peer means winning across three independent networks at once.
Pinning a small number of addnode=... entries to peers the operator personally trusts, including peers reached via .onion, adds another layer. These manual connections do not count against the auto-managed peer slots and are retried aggressively.
A related setting governs pruned nodes. BIP 159's NODE_NETWORK_LIMITED service bit (0x400) lets a pruned node signal that it still serves at least the last 288 blocks, so it contributes to peer connectivity without storing the full chain.
Firewall and Host Hardening
A node that does not listen for inbound connections has no Bitcoin-specific firewall surface beyond outbound. A listening node needs exactly one public port open: 8333 for mainnet (18333 for testnet). Every other port should be blocked from the public internet. A typical UFW (Uncomplicated Firewall) policy denies inbound by default, allows SSH from a known administrative range, and allows 8333 from anywhere.
Two ports should never reach the public internet: the RPC port (8332 default) and the Tor control port (9051 default). Both grant control over the node and its keys to anyone who can reach them. If remote RPC access is required, the right path is an SSH (Secure Shell) tunnel from the operator's workstation to the node, never an open firewall rule.
RPC Discipline
The Bitcoin Core RPC interface should use rpcauth rather than the legacy rpcuser and rpcpassword settings. rpcauth stores a salted SHA-256 hash in bitcoin.conf, so the plaintext password never lives on disk in the config file. The share/rpcauth/rpcauth.py helper in the Bitcoin Core source generates the hash and the matching password on demand.
Two further settings tighten the RPC surface. rpcallowip restricts which source addresses may connect; the default value of 127.0.0.1 accepts only loopback and should be widened only with a specific reason. rpcbind controls which interfaces the RPC server listens on; binding to 127.0.0.1 only is the safe default. Removing both restrictions, even briefly, exposes the wallet to credential-stuffing and known-vulnerability scans within hours.
Backups
Two backup artifacts matter. The wallet file backup or exported output descriptor for any wallet the node holds is the canonical restore artifact and belongs on offline media stored in at least two physical locations. The wallet.dat file is a convenience backup that captures non-descriptor state such as address labels and watch-only keys; encrypting the file before copying it off the node is mandatory if the wallet is encrypted in place.
The blockchain itself does not need backing up. A reinstall reads it from peers in the time it takes to download and validate, which on modern hardware runs from a few hours to a couple of days depending on the connection.
Wallet-Side Privacy
Running a self-hosted node already eliminates the largest single privacy leak: the third-party server that learns every address the wallet queries. Beyond that baseline, three habits keep the wallet's transaction graph from being deanonymized:
- Generate a new receive address for every payment. Reusing an address aggregates incoming payments under one observable identity.
- Use coin control when spending, so the inputs to a transaction reflect the privacy posture the operator intends. Mixing inputs from unrelated payments merges those identities permanently on chain.
- For watch-only setups, the disable_private_keys flag at wallet creation prevents the node from ever holding spend authority for the addresses it tracks.
Operational Mistakes That Leak Privacy
A correctly configured Tor proxy does not protect against a misconfigured DNS (Domain Name System) resolver. If Bitcoin Core resolves peer hostnames through the system resolver rather than through Tor, the resolver's logs (or the ISP's DNS records) capture the lookups. Setting dns=0 in bitcoin.conf and providing peers as IP addresses or .onion addresses closes this leak.
Sharing a single node between personal wallets and a custodial or business service collapses the personal wallet's privacy to whatever the service tolerates. If the service logs RPC requests, those logs reveal the personal wallet's queries.
Broadcasting transactions over a clearnet connection while running the rest of the node over Tor reattaches the operator's IP address to the transactions the node originates. The fix is to wallet-broadcast through the node and ensure the node's outbound transaction relay uses the same anonymity network as the rest of its traffic.
Frequently Asked Questions
Does running a Bitcoin node over Tor slow it down?
Tor adds latency to peer connections and can lengthen initial block download (IBD) compared to clearnet. Once synced, ongoing relay and validation feel similar to a clearnet node; Bitcoin's traffic volume is modest relative to Tor's per-circuit throughput.
Is BIP 324 enabled by default in Bitcoin Core?
Yes. BIP 324 v2 transport has been enabled by default since Bitcoin Core 27.0 and is negotiated automatically when both peers support it. v1 fallback remains in place to preserve connectivity with older nodes.
What is the difference between Tor and i2p for a Bitcoin node?
Tor and i2p are different anonymity networks. Tor has more Bitcoin peers and is easier to set up, while i2p offers a different threat model and a separate peer set. Running both, alongside clearnet, raises the attacker surface required to eclipse the node.
Do I need to open port 8333 to run a secure node?
No. A node that does not accept inbound connections is still a fully validating node. Opening port 8333 makes the node useful to other operators by accepting inbound peers but is not a security requirement.
How do I store the wallet passphrase safely?
The passphrase belongs in a password manager (KeePassXC, Bitwarden, 1Password) on a device that is not the node itself. Writing it on paper is acceptable as a tertiary backup if the paper is stored in a controlled location separately from the recovery phrase.
Run a Node, Hold Bitcoin Self-Custodially
A hardened node is the foundation for self-custodial Bitcoin operations. Pair it with a Blockstream Jade hardware wallet for offline key storage and the Blockstream app for everyday transactions, and the result is a self-custodial stack whose privacy and security depend on the operator, not on any third party.