Whoa. Running a full node is less mysterious than it feels. It also rewards patience. If you’re an experienced operator or miner, this is where you stop guessing and start tuning—hard choices, tradeoffs, and a few gotchas that only show up at scale.

Short version: prioritize disk throughput and network reliability. Medium version: pick good storage, set dbcache aggressively, and avoid turning on experimental flags on production miners. Longer version: balance archival needs against operational costs, understand IBD behavior, and make your node resilient to reorgs and DDoS.

I’ve run nodes on colo racks, consumer gear, and cloud VMs. Each environment teaches one thing: the defaults are conservative for a reason, but you can do better without risking consensus. Here’s a practical checklist and the reasoning behind it.

Hardware and OS — what actually matters

CPU: modest. Single-threaded verification is the bottleneck during IBD and rescans. Modern mid-range CPUs are fine for steady-state operations, but expect heavy CPU use when validating newly downloaded blocks.

RAM: give Bitcoin Core some room. Set dbcache based on available RAM. For a mainnet archival node, 8–16 GB is a common sweet spot; for a miner or busy explorer node, 32 GB+ helps. If you run multiple services (pool software, monitoring, etc.) factor those in.

Disk: SSDs matter. NVMe is best for initial block download (IBD) and chainstate churn. Throughput and IOPS beat raw capacity. Cheap SATA SSDs will work; avoid slow HDDs unless you prune. Also, RAID arrays can add complexity—prefer single high-quality SSDs with reliable backups.

Network: low latency and stable bandwidth. Peers heal quickly when your egress is solid. If you plan to relay large blocks or participate in mining, ensure symmetric bandwidth where possible. Use a static IP or stable dynamic DNS for miners that expect fixed peers.

Configuration knobs that change everything

dbcache: raise this. Default is tiny. For a full archival node, pushing dbcache to several GBs (8–16 GB) reduces disk I/O dramatically during IBD and reindex operations.

prune vs archival: prune saves space but removes historical blocks. If you’re mining or need historical data for analytics, don’t prune. If you only validate current consensus and want low storage footprint, pruning (e.g., 550 MB min to a few GB) is fine. Be deliberate—prune is a one-way street unless you re-download the chain.

txindex / addrindex: enable txindex if you need RPC access to arbitrary transaction lookups. It costs disk and indexing time. There’s no addrindex flag in Bitcoin Core upstream; third-party patches provide that and bring operational risk.

assumevalid / checkblocks: trust but verify. The default assumevalid speeds up verification during IBD by skipping expensive script checks for deep historic blocks. Only adjust this if you understand the security tradeoffs.

Initial Block Download (IBD) — speed it up responsibly

IBD is the pain point. It reads the entire blockchain, verifies blocks, and builds the UTXO set. Use fast storage. Use reliable peers—addnode entries or connect to trusted peers if you have them. Avoid arbitrary snapshot downloads from untrusted sources; they save time but introduce trust assumptions.

Snapshots and UTXO loads: some operators use vetted snapshots to jumpstart IBD. If you go that route, verify the provider and use signed manifests where possible. A clean IBD from the network is the safest path, though slower.

Networking, peers, and privacy

Set up good peer management. Increase maxconnections if you want to be well-connected (the default is conservative). Use peerbloomfilters only if you understand privacy loss; they are deprecated for light clients but still relevant in certain setups.

Tor: run in Tor if you want inbound privacy. It’s slower, and IBD will take longer through Tor circuits. A common approach is: do a direct IBD over clearnet on good bandwidth, then switch to Tor for steady-state privacy-sensitive operation.

Mining integration: miner-friendly settings

For miners, low-latency block propagation is paramount. Reduce block relay latency by using high-quality network links and set up multiple connected full nodes in different networks as fallback. Use getblocktemplate and make sure your node’s mempool and fee estimation are healthy.

Watch out for mempool policies: miners rely on accurate fee estimates. If your node has restrictive minrelaytxfee or aggressive pruning, your fee signals may be off. Also, txindex is not required for mining, but certain pool setups and explorers depend on it.

Security: backups, keys, and attack surface

Keep backups of wallet.dat and encryption passphrases. Make regular snapshots of config and any automation scripts. But don’t store private keys on exposed machines—use hardware wallets or dedicated signing machines for hot/cold separation.

RPC exposure: do not expose RPC ports publicly. Use VPN, SSH tunnels, or tor+auth to manage nodes remotely. Harden the OS: disable unnecessary services, enable automatic updates where appropriate (but test upgrades on a staging node first), and use monitoring to catch anomalies fast.

Operational habits that save headaches

Monitor disk health and available space. Full nodes can hit unexpected peaks (reindexing, large mempool spikes). Alert before the disk fills—full disks during database writes are nasty.

Upgrade policy: run a staging node with the new release for a few days before pushing to miners. Bitcoin Core releases are vetted, but third-party integrations can break. Rolling upgrades are safe for nodes; miners should coordinate software and network changes.

Logging: keep logs rotated and scraped into a central monitoring system. Use metrics: block height, IBD percent, mempool size, peer count, and last block timestamp. These give early warning of issues.

Common gotchas and how to avoid them

IBD stalls: check disk I/O and peer connectivity. A busy network or slow disk causes stalls. Reindexing takes time—plan maintenance windows.

Pruned node limits: pruned nodes can’t serve historical blocks. If you’re asked for block data by miners or explorers, you’ll disappoint them. Document your node’s capabilities.

Reorg handling: small reorgs are normal. Big reorgs are rare. Miners should implement reorg-safe practices: wait for confirmations appropriate to their risk model and handle orphaned blocks in payout logic.

Where to learn more and a practical tip

If you want the authoritative reference for configuration and behavior, check the official documentation and release notes. For quick reference and downloads you can look at the bitcoin project pages such as bitcoin. Use that alongside release notes, and cross-check before changing defaults on production miners.

Practical tip: run at least two nodes in different networks—one for mining and low-latency relay, another for archival/analytics or as a fallback. It buys resilience without too much extra cost.