Node Types: Full, Pruned, SPV & Archival

The word “node” hides a spectrum. Some machines re-derive the entire history of Bitcoin from first principles and trust no one; others ask a peer “is my payment in a block?” and take the answer on faith. The difference is not cosmetic — it’s the difference between verifying the rules and trusting someone else to. This page sorts out who checks what, who stores what, and why the distinction is the beating heart of Bitcoin’s “don’t trust, verify” ethos.

The two questions every node answers differently

Every node design is really a set of answers to two questions:

1. Do I validate every rule myself, or do I trust someone’s summary?
2. How much of history do I keep on disk?

Hold those two axes in mind; the node “types” are just named points on them.

Full node — the sovereign verifier

A full node downloads every block and independently checks every consensus rule: each signature, that no coin is spent twice, that the 21-million supply schedule is obeyed, that every script executes correctly, that the proof of work is valid (see block validation). It builds and maintains its own copy of the UTXO set — the live record of who owns what — by replaying history.

Crucially, a full node accepts a block only if it passes its own rules, no matter who sent it or how much hash power is behind it. A miner can spend a billion dollars producing an invalid block; your full node will reject it in milliseconds and move on.

This is what “don’t trust, verify” means

When you run a full node and your wallet connects to it, you are the authority on whether you were paid. No bank, no block explorer, no miner. You can audit the entire money supply yourself with one command. This is the most concrete form of self-sovereignty Bitcoin offers — see running a node.

Pruned node — full validation, less disk

A common misconception: that discarding old blocks means you’re “less of a node.” Not so. A pruned node validates exactly as rigorously as an archival one — it downloads and fully verifies every block from genesis forward — but after a block is checked and folded into the UTXO set, it deletes the raw block data it no longer needs, keeping only a recent window (e.g. the last ~550 MB).

This works because of a deep insight from the UTXO set vs the chain: the state you need to validate new transactions is the UTXO set, not the full history. The chain is the audit trail that produced the current state; once you’ve personally verified that trail, you can throw the trail away and keep the conclusion. A pruned node is still a first-class verifier — it simply can’t serve old blocks to others.

SPV / light client — trust headers and proofs

An SPV (Simplified Payment Verification) client, sketched in the original whitepaper, does not validate the rules. It downloads only the block headers — the ~80-byte summaries that include the proof of work and the Merkle root — and asks full-node peers for Merkle proofs that a given transaction is included in a given block.

Full node:   "I checked every rule myself."
SPV client:  "I verified there's valid proof-of-work above this block,
              and a Merkle proof that my tx sits inside it.
              I'm TRUSTING that the rules inside the block were obeyed."

This is cheap enough to run on a phone, but the tradeoffs are real:

• It assumes the most-work header chain is the valid one — it cannot detect an invalid block (e.g. one that prints extra coins) because it never checks the rules; it only checks that work was done.
• It leaks privacy: naively asking peers about your addresses tells them which coins are yours (real wallets use BIP 157/158 compact block filters or other tricks to blunt this).
• It depends on honest peers to surface relevant transactions and not hide them.

SPV is a reasonable bargain for small balances on constrained devices — but it trades verification for trust, which is exactly the thing a full node refuses to do.

Archival node — keeper of the full history

An archival node is a full node that keeps every block ever mined on disk (hundreds of GB and growing). It validates everything and retains the complete chain, so it can serve any historical block to new nodes performing initial block download or to explorers reconstructing old transactions. Archival nodes are how a brand-new node can bootstrap from genesis at all — somebody has to still have block 1.

Comparison

Property	Archival full	Pruned full	SPV / light
Validates every consensus rule	Yes	Yes	No (trusts headers)
Builds its own UTXO set	Yes	Yes	No
Stores full block history	Yes	No (recent window)	No
Can serve old blocks to peers	Yes	No	No
Detects an invalid block	Yes	Yes	No
Typical disk	Hundreds of GB	A few GB	Tens of MB
Trust model	Trust no one	Trust no one	Trust most-work + peers

Miners are not a separate trust tier

A mining node is just a full node that also assembles candidate blocks and runs proof of work. It still validates everything. Mining is about proposing the next block; validation power — the right to reject — stays with every full node, miner or not.

By the numbers — what each node actually costs in disk

The “validate everything” guarantee is surprisingly affordable, because the state you must keep is far smaller than the history you verify.

full block history (archival)   ≈ hundreds of GB   (north of ~500 GB by the mid-2020s, growing)
live UTXO set (the state)       ≈ a few GB          (roughly 5–10 GB)
pruned node on disk             ≈ a few GB           (UTXO set + a ~550 MB rolling block window)
SPV / light client              ≈ tens of MB         (headers only: ~80 bytes × 800,000+ blocks)

A pruned node throws away the bulk of the download after checking it, yet keeps the exact same security as an archival one — concrete proof of the UTXO-set-vs-chain insight that the conclusion is tiny even though the audit trail is huge.

The thread

How does this help untrusting strangers agree on one ledger? Because the strongest participants — full nodes, pruned or archival — never take anyone’s word for the ledger’s contents. Each derives the truth independently from the rules. SPV clients lean on that crowd of verifiers; their security is borrowed from the full nodes around them. The more people who verify for themselves, the harder it is for anyone to slip a false ledger past the network.

The architect’s lens

The node “types” aren’t an accident of history — they’re deliberate points on a verify-vs-trust dial:

• Why does it exist? So anyone can be their own authority on the ledger: a full node re-derives every consensus rule — each signature, the no-double-spend rule, the 21-million supply schedule — and accepts a block only if it passes its own checks, regardless of the hash power behind it.
• What problem does it solve? Trust delegation. It removes the bank, the block explorer, and the miner as oracles — you can audit the entire money supply with one command rather than asking someone whether you were paid.
• What are the trade-offs? Resources bought with trust: archival ≈ hundreds of GB; pruned ≈ a few GB (full security, but can’t serve old blocks); SPV ≈ tens of MB but verifies nothing — it trusts the most-work header chain plus honest peers, leaks privacy, and can’t detect a block that prints extra coins.
• When should I avoid it? A full node is overkill on a phone or a tiny constrained device holding a small balance — SPV’s borrowed security is a fair bargain there. For any meaningful balance, a merchant, or a miner, you want to validate yourself.
• What breaks if I remove it? If everyone ran SPV there’d be no full nodes left to borrow security from — no independent verifiers to reject a fraudulent block — and “don’t trust, verify” collapses back into “trust whoever serves you headers.”

Check your understanding

1. What are the two independent axes that distinguish node types, and where does each type fall on them?
2. Why is a pruned node still a full validator despite deleting old blocks? What state must it keep?
3. What exactly does an SPV client verify, and what does it merely trust?
4. Why can an SPV client fail to notice a block that prints extra coins, while a full node cannot?
5. Why is a mining node not a higher “trust tier” than an ordinary full node?

Show answers

1. The two axes are: (1) do I validate every rule myself, or trust someone’s summary? and (2) how much of history do I keep on disk? Archival full nodes validate everything and store all history; pruned full nodes validate everything but keep only a recent window; SPV clients validate nothing (trust headers) and store almost nothing.
2. A pruned node downloads and fully validates every block from genesis forward — it just deletes the raw block data after folding each block into its state. The state it must keep is the UTXO set: once you’ve personally verified the audit trail, you can discard the trail and keep the conclusion. It simply can’t serve old blocks to others.
3. It verifies that there is valid proof of work above a block (the most-work header chain) and a Merkle proof that its transaction sits inside that block. It merely trusts that the consensus rules inside the block were obeyed — it never checks them.
4. An SPV client never checks consensus rules; it only checks that work was done, so a block that prints extra coins still carries valid PoW and a valid Merkle proof and passes. A full node validates the supply schedule itself and rejects the block in milliseconds regardless of its work.
5. A mining node is just a full node that also assembles candidate blocks and runs proof of work — it still validates everything. Mining is about proposing the next block; the power to reject invalid blocks stays with every full node, miner or not.