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 — substitute the current version)
tar -xzf bitcoin-31.0-x86_64-linux-gnu.tar.gz
sudo install -m 0755 bitcoin-31.0/bin/* /usr/local/bin/

# Confirm it's there
bitcoind --version

Bitcoin Core version v31.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 / testnet4) 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     ~15–20 GB (chainstate dominates)

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

Example output (an illustrative mid-sync snapshot — your blocks, size_on_disk, and progress will differ):

{
  "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.

Under the hood — what assumevalid actually skips

The page says your node “checks every signature.” By default it’s subtler — and faster. Each Bitcoin Core release ships with an assumevalid setting: the hash of a deeply-buried block that the developers (and anyone who looks) know is real. For blocks below that point, Core skips the expensive signature/script checks while still verifying proof of work, that every input exists and isn’t double-spent, and the entire supply schedule. Skipping only old signatures — already protected by a mountain of proof of work piled on top of them — cuts initial sync time dramatically without weakening the rules that decide who owns what.

It’s a convenience, not a trust assumption you’re stuck with. Set assumevalid=0 and your node will verify every signature from the genesis block forward, no shortcuts taken. That the option exists is the whole point: you can always choose to re-derive the entire ledger yourself, byte for byte.

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?

Show answers

1. Open-ended — e.g. on a fresh signet node mid-sync you might see blocks: 120000, headers: 180000, verificationprogress: 0.67. blocks is how many full blocks are downloaded and verified, headers the height of the skeleton already fetched, and verificationprogress the fraction of the way to the tip. You’re fully synced when blocks == headers and initialblockdownload flips to false.
2. A pruned node downloads and fully validates every block from genesis — it just deletes old block data after checking it, keeping only a recent window. It still enforced every consensus rule on the way down. What it can’t do is serve arbitrary old raw transactions or rescan deep history to other peers.
3. txindex=1 indexes every transaction, so you can look up any txid (not just your wallet’s) with commands like getrawtransaction. It’s incompatible with prune because pruning deletes the old block data that such an index would need to reference.
4. Because your node independently checks every rule — proof of work, every signature, the supply schedule, every script — and rejects any block that breaks them no matter who sent it or how much work it carries. You don’t take anyone’s word for the ledger; you derive it yourself, which is the literal meaning of “don’t trust, verify.”
5. Headers come first because they’re tiny (~80 bytes each) and let the node cheaply verify proof of work and pick the most-work chain before downloading heavy block bodies. This headers-first approach also lets it fetch the bodies in parallel from many peers, so headers races to the tip while blocks catches up behind it. (See initial block download.)