Step 6: your own node

Wonder

1. How does a user verify that the software they downloaded has not been altered by a man-in-the-middle or a compromised repository?
2. Why is connecting to a public server for balance checks equivalent to revealing one’s financial status to a third party, and how do local indexers resolve this?
3. What is the difference between validating a transaction through a remote authority and independently checking its rules against the chain?

Explore

1. Bitcoin Core (lesson 3.1.5) validates every block from genesis to head, ensuring each meets the consensus rules. Before running any version, users must verify integrity using SHA256SUMS and SHA256SUMS.asc files. These contain cryptographic hashes signed by multiple independent builders. By importing their GPG public keys and verifying the signatures, a user confirms that the binary matches what trusted developers released, preventing execution of tampered code that could steal keys or corrupt data.
2. The initial block download (IBD) fetches and checks the whole chain, well over 600 GB, and takes from several hours to days depending on hardware and connection. A full node keeps that history on disk. A pruned node validates every block but keeps only recent ones (the minimum setting is prune=550, in MiB), so with the UTXO set it fits in roughly 10–20 GB. Both types enforce consensus rules independently, allowing users to reject invalid transactions before they enter their own mempool.
3. Software wallets typically connect to remote servers to fetch balance information and broadcast transactions. This reveals the wallet’s addresses and balances to that server operator. To maintain privacy, users can run a local Electrum server implementation such as Fulcrum or electrs alongside Bitcoin Core. These indexers expose an API compatible with standard wallets but operate locally on the user’s machine. Connecting the wallet to this local instance ensures that address history and balance data never leave the user’s network perimeter.
4. Direct RPC connection is another method for integrating a wallet with Bitcoin Core, bypassing intermediate servers entirely. This approach allows advanced users to customize transaction construction and fee logic directly against their own node. Whether using RPC or an Electrum-compatible indexer, the critical distinction is that the data source is owned by the user. The node checks the UTXO set locally, confirming funds are unspent and valid according to protocol rules before signing anything.
5. Running a node shifts trust from centralized intermediaries to mathematical verification. A local node also broadcasts the user’s own transactions, so no wallet server can quietly refuse or log them. The trade-off is hardware cost and maintenance responsibility: users must handle software updates, disk expansion, and uptime. However, this autonomy ensures that the failure of any single entity—exchange, wallet provider, or server operator—does not result in loss of access or control over funds.
6. Check the setup. In Bitcoin Core run getblockchaininfo and confirm that blocks equals the current height on a public explorer and that initialblockdownload is false; compare getbestblockhash with the explorer’s latest block hash. In the wallet’s server settings, confirm it points to your own node or Electrum server and not a public one. If balances load with the public servers switched off, the wallet is reading from your node.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Bitcoin Core, 'Download Verification Instructions' (bitcoincore.org)
• Sparrow Wallet, 'Connect to Bitcoin Core' guide
• electrs documentation (github.com/romanz/electrs)