Running Your Own Node

The slogan of Bitcoin is “Don’t trust, verify.” Up to now you’ve trusted us to describe how the chain works. Running your own full node ends that: your machine downloads every block, checks every signature, recomputes every Merkle root, and enforces every consensus rule for itself. It accepts no block on anyone’s say-so. That is what makes you a peer rather than a customer — and it’s the bedrock answer to our recurring question: how do untrusting strangers agree on one ledger? They don’t agree by trusting each other. They each run the same rules and arrive at the same answer independently.

Why bother running one

• Sovereign verification. A node you control is the only way to know — not be told — that a payment to you is valid and buried under real work. No third party can lie to your own node.
• Privacy. When you query a block explorer, you reveal which addresses you care about. Your own node answers your wallet’s questions locally.
• You enforce the rules. Every full node is a vote for the ruleset. Miners propose; nodes dispose. A block that breaks the rules is rejected by your node no matter how much work it carries.

Install Bitcoin Core

Bitcoin Core is the reference implementation — bitcoind (the daemon) plus bitcoin-cli (the control tool). Download from bitcoincore.org and, crucially, verify the release signatures and hashes before running it. Verifying the binary is the same “don’t trust, verify” reflex applied to the software itself.

# macOS (Homebrew) — convenient, but verify the formula's source
brew install bitcoin

# Debian/Ubuntu from the official tarball (sketch)
tar -xzf bitcoin-27.0-x86_64-linux-gnu.tar.gz
sudo install -m 0755 bitcoin-27.0/bin/* /usr/local/bin/

# Confirm it's there
bitcoind --version

Bitcoin Core version v27.0.0

The config file: bitcoin.conf

Bitcoin Core reads a single config file. Its location is the data directory — ~/.bitcoin/ on Linux, ~/Library/Application Support/Bitcoin/ on macOS. A sane starter config:

~/.bitcoin/bitcoin.conf

# Run the JSON-RPC server so bitcoin-cli can talk to the daemon
server=1

# Index every transaction (lets you look up ANY txid, not just your wallet's).
# Costs extra disk; invaluable for learning.
txindex=1

# Be polite to the network: accept inbound connections if your firewall allows
listen=1

# Cache for the UTXO database — more RAM here = faster initial sync
dbcache=2000

Start on a test network while you learn

Append chain=signet (or regtest / testnet) and your node lives on a sandbox chain with no real money. We cover all three in Testnet, Signet & Regtest. Do your first experiments there.

The pruning option

A full archival node stores the entire chain — hundreds of gigabytes and growing. You do not need to keep old blocks to fully validate; you only need them to serve history to other peers. Pruning lets you validate everything from genesis, then discard old block data once it’s checked:

# Keep only the most recent ~5 GB of block files. Mutually exclusive with txindex.
prune=5000

A pruned node is still a full-validation node — it checked every rule on the way down. It just can’t hand you an arbitrary old raw transaction or rescan deep history. For a learning node with the disk to spare, prefer txindex=1; for a Raspberry Pi, prune.

            ARCHIVAL                 PRUNED
  validates every rule?   yes          yes
  stores all old blocks?  yes          no (keeps ~N MB)
  can serve full history? yes          no
  disk needed (mainnet)   ~600+ GB     ~10 GB

Start the daemon

# Foreground (watch the logs scroll); Ctrl-C to stop
bitcoind

# Or detach into the background
bitcoind -daemon

Bitcoin Core starting

It immediately begins Initial Block Download (IBD) — fetching and verifying the chain from peers (see the P2P protocol for how it finds them). This is not a passive download: every block is checked against Proof of Work, every signature is verified, every output is tracked into the UTXO set. On mainnet IBD can take many hours to a couple of days.

Check the sync

The first command you’ll run constantly:

bitcoin-cli getblockchaininfo

{
  "chain": "main",
  "blocks": 812345,
  "headers": 845000,
  "bestblockhash": "0000000000000000000223...e9a1",
  "difficulty": 79528282476189.41,
  "verificationprogress": 0.9612,
  "initialblockdownload": true,
  "size_on_disk": 612043997184,
  "pruned": false
}

Read it like a dashboard:

• blocks vs headers — headers come first (fast), full blocks follow. When blocks catches up to headers, you’re synced.
• verificationprogress — fraction of the way to the tip (0.96 = 96%).
• initialblockdownload: true — still catching up. Flips to false when current.
• bestblockhash — the tip your node has independently chosen as the most-work chain.

When initialblockdownload reads false and blocks == headers, your node has independently reconstructed and verified the entire ledger. Nobody told you the balance of any address — your machine derived it. That is sovereign verification.

Don’t put real funds on a node you’re still learning with

Keep your experiments on signet/regtest. We’ll only touch keys and coins on test networks throughout this part. Never paste a mainnet seed phrase into anything you’re poking at for the first time.

The thread

A node is the physical embodiment of trust-minimized consensus. Ten thousand strangers, none trusting the others, each run bitcoind, each apply the identical rules to the identical blocks, and each arrive at the same single ledger — not by agreement, but by independent verification of the same expensive-to-forge history.

Check your understanding

1. Start bitcoind on signet and run getblockchaininfo. What are blocks, headers, and verificationprogress right now?
2. Why is a pruned node still a full-validation node? What can’t it do?
3. In bitcoin.conf, what does txindex=1 buy you, and why is it incompatible with prune?
4. Explain why “your node accepts no block on anyone’s say-so” is the real meaning of “don’t trust, verify.”
5. Watch blocks and headers over a few minutes during IBD. Why does headers race ahead first?