Okay — let’s cut to it. If you’re already comfortable with the basics of Bitcoin and want a robust, privacy-respecting, reliable full node, this is for you. I’ll share real-world tips that I use when I spin up a node: hardware tradeoffs, bitcoin.conf knobs that matter, initial block download (IBD) strategies, Tor integration, maintenance, and common pitfalls. No hand-holding — just useful, actionable things that actually save time and reduce headaches. First impressions matter: a full node is both a public service and a personal tool. It validates consensus for you, enforces your own rules, and gives you trust-minimized access to your coins. But running one well takes more than clicking “download” — there’s planning around storage, network, and verification that you don’t want to improvise. Hardware baseline: NVMe or SATA SSD (NVMe preferred), 4+ cores, 8–16 GB RAM, reliable power and a decent uplink. If you have an older spinning disk, consider using it only for backups. Disk throughput matters during IBD; random-read/write latency matters later. My practical baseline: an NVMe for blocks and chainstate, plus a cheap USB3 external drive for backups and optional pruned archival snapshots. Configuration essentials and bitcoin.conf Here are the flags and config entries that actually change behavior in meaningful ways: datadir=/path/to/datadir — choose the right disk ahead of IBD. prune=550 — if you want to save space but still serve and validate recent history. Set to 0 for archival nodes. dbcache=4000 — increases RAM used for DB caching; helps speed up IBD on machines with lots of RAM. Be conservative: leaving the OS some headroom matters. txindex=1 — only if you need to query arbitrary txids locally. It increases disk and rebuild time significantly. assumevalid=0 — if you’re paranoid and want to reverify everything yourself, set to 0 (default behavior changed over versions; check what your release does). listen=1 and bind=0.0.0.0 — accept inbound peers; pair with firewall rules and port forwarding if you’re behind NAT. blocksonly=0 — keep this 0 unless you want to reduce mempool relay traffic and bandwidth. externalip=your.public.ip — helpful if you have dynamic situations and want stable peerability (dynamic DNS often better). Pro tip: if you set prune, don’t enable txindex — they are generally at odds for archival uses. Also, increasing dbcache helps IBD speed, but it makes your node more memory-hungry, and when the OS starts swapping, you lose performance badly. Initial Block Download strategies IBD is the time sink. Several approaches: Fast lane: Download blocks over a high-bandwidth connection and use a machine with high dbcache and NVMe. Expect 24–72 hours depending on hardware and bandwidth. Seeded restore: Use a trusted, recently-synced machine on your LAN to copy the blocks directory locally — reduces download time but increases trust in the initial host (you’re trusting filesystem copy integrity). Bootstrap via snapshot: Some folks distribute snapshots; fine for speed, but you should reindex and verify headers and chain integrity yourself if you care about trust-minimization. Commands I run frequently during IBD monitoring: bitcoin-cli getblockchaininfo and bitcoin-cli getnettotals and bitcoin-cli getpeerinfo. They tell you where the sync is, download rates, and who you’re connected to. If you see lots of inbound peers but no headers syncing, check RPC logs and peer banlists — sometimes a misconfigured firewall or stale Tor proxy causes weird stalls. Network, privacy, and Tor Want privacy? Run over Tor. It’s no panacea, but it helps decouple IPs. Practical setup: Install Tor and expose a hidden service: set proxy=127.0.0.1:9050 and listenonion=1 in bitcoin.conf. Bind a Tor hidden service for your node’s P2P port; that lets other Tor nodes connect to you without revealing your IP. Keep an IPv4/IPv6 fallback if you need reachability outside Tor; otherwise, you can run purely as a Tor-only node. Note: Tor adds latency and can make IBD slower, so IBD over clearnet then switch to Tor, or use a hybrid approach depending on threat model. Also, avoid running public SOCKS proxies on the same host that you use for browsing — separation reduces correlation risk. Wallets, backups, and operational hygiene I’m biased: keep wallet keys off your everyday machine. If you’re using Bitcoin Core’s built-in wallet, make frequent backups, and use walletpassphrase for operations that require it. For advanced users: consider using descriptor wallets and external signer workflows (PSBT) so your private keys are on air-gapped devices. Backup tips: Regularly export descriptors or use dumpwallet only as needed; wallet.dat contains metadata that’s easy to corrupt across versions. Store backups encrypted on multiple devices and off-site if needed. A simple USB stick isn’t enough if it’s your only copy. When upgrading versions, read release notes. Automatic upgrades can be fine, but major consensus-related changes need attention. Maintenance, monitoring, and logs Crucial commands and checks: bitcoin-cli getblockchaininfo — sync state, verification progress. bitcoin-cli getpeerinfo — connected peers, inbound/outbound, subversion strings. tail -f ~/.bitcoin/debug.log — for errors, reorgs, and unusual warnings. Set up simple monitoring: disk free, process up, and peers count alerts. Small infra ops: rotate logs, ensure a UPS for graceful shutdowns, and script cold backups. If you’re running a hosted node, watch bandwidth quotas; a node serves several GB/day depending on peer count and block relay behavior. FAQ Do I need to run a full node to use my wallet? No — light wallets work fine. But a local full node gives you direct validation and privacy benefits: you don’t have to trust third-party servers for block and transaction validity. For high-value or privacy-focused users, it’s worth it. What’s the difference between pruning and txindex? Pruning reduces disk usage by discarding old block files once they’re spent and not needed for current validation; txindex builds an index of all transactions so you can query any txid locally. You can’t have a low-prune archival txindex simultaneously: archival nodes keep everything and can run txindex, pruned nodes usually don’t.