Bitcoin

Running a Bitcoin full node is one of the most meaningful things you can do with self-hosted infrastructure. Not because it earns anything, it does not, but because of what it changes about your relationship with the network.

When you transact using a light wallet or a custodial exchange, you are trusting someone else’s node to tell you the truth about your balance, the current state of the blockchain, and whether a transaction has been confirmed. That trust is usually well-placed. But it is still trust, and it is the kind of trust that the entire architecture of Bitcoin was designed to make unnecessary.

A full node trusts no one. It downloads every block from genesis, validates every transaction against the consensus rules, and reaches its own independent conclusions. Your balance is verified locally. Your transactions are broadcast without revealing your addresses to a third party’s server. The 21 million supply cap is enforced by your own software.

A regular full node does not earn you any bitcoin. It is not mining. The value you get is privacy, independence, and the ability to verify your own transactions without trusting anyone.

What this section covers

The Bitcoin section of this series covers three components:

Bitcoin Core (full node): the reference implementation of the Bitcoin protocol. It downloads and validates the complete blockchain, maintains a mempool of unconfirmed transactions, relays transactions and blocks to peers, and provides an RPC interface for wallets and applications. This is the foundation that everything else depends on.

Electrum Server (Electrs): a personal Electrum protocol server that indexes the blockchain and allows Electrum wallets to query your own node rather than a public server. Without a personal Electrum server, the Electrum wallet connects to third-party servers that can see your addresses and transaction history. With Electrs running locally, the wallet connects to your own server and that information stays private.

Additional components such as Lightning Network (LND or Core Lightning) are natural extensions of this setup and are planned as follow-on pages once the core node is running.

The case for a full node

Three reasons, each distinct.

Privacy. A light wallet using a third-party server leaks your addresses and transaction history to that server’s operator. They can link addresses to each other, correlate activity over time, and in some cases connect it to identifying information. A full node with a personal Electrum server eliminates this: queries go to your own server which knows the full blockchain but does not phone home with your activity.

Sovereignty. You independently verify the rules of the network. Nobody can tell you that a block is valid if it is not, that a transaction was confirmed if it was not, or that the supply exceeds 21 million coins. Your node is the final arbiter of what is and is not valid Bitcoin.

Contribution. A well-connected full node with good upload bandwidth strengthens the network. New nodes downloading the blockchain for the first time rely on existing nodes to serve them the data. Running a node that accepts inbound connections and serves blocks to peers is a meaningful contribution to network health.

Hardware requirements for February

The blockchain as of early 2026 is over 600GB. With the Electrum index on top, plan for at least 1TB of storage for a full archival node. A pruned node, which stores only the most recent blocks rather than the complete history, requires significantly less space but cannot serve historical blocks to peers or run an Electrum server.

For this network, a full archival node is the correct choice. The February server has:

• Storage: 8 x 4TB Ironwolf HDDs in a ZFS pool, with capacity to spare for the blockchain. The blockchain should sit on the ZFS pool rather than the NVMe drives since it is large and sequential-access rather than latency-sensitive.
• RAM: 128GB, far more than Bitcoin Core needs (it uses 2-4GB under normal operation)
• CPU: Ryzen 7 5700X, sufficient for validation and indexing
• Connectivity: residential broadband, adequate for node operation

The one constraint worth noting: it is common for full nodes on high-speed connections to use 200GB in uploads or more a month. Monitor bandwidth usage in the first month and configure upload limits in Bitcoin Core if the residential connection has data caps.

Architecture in this series

Bitcoin Core and Electrs run in a dedicated LXC container. The blockchain data directory is on NFS-mounted ZFS pool storage rather than inside the container, so the blockchain survives container rebuilds and is accessible to backup and monitoring.

The container exposes the Bitcoin Core P2P port (8333) to the internet via the UDM-SE for inbound peer connections. The RPC port and Electrum server port are internal only, accessible via the WireGuard VPN.

The Electrum wallet on the desktop connects to the Electrs server via the VPN, giving full node security and privacy from anywhere.

Initial block download

The first sync of Bitcoin Core, downloading and validating the complete blockchain from genesis, takes time. On a modern computer with an SSD and solid internet, IBD takes anywhere from a few days to over a week depending on disk speed and bandwidth.

The ZFS pool uses spinning hard drives rather than SSDs. This will extend the IBD duration compared to an SSD setup. The blockchain data is write-intensive during IBD: the sequential write performance of the Ironwolf drives is adequate but slower than NVMe or SATA SSD.

If IBD duration is a concern, temporarily pointing Bitcoin Core’s data directory at one of the Crucial 1TB SSDs for the initial sync, then moving to the ZFS pool once caught up, is a practical approach. The blockchain can be moved between storage locations while Bitcoin Core is stopped.

Once the initial sync is complete, daily operation is quiet and low-impact. Bitcoin Core syncs new blocks as they arrive (roughly every 10 minutes) and relays transactions continuously without significant resource usage.