Pruned node

Pruning trades history for disk space, and it costs you nothing in security. Bitcoin Core has supported it since version 0.11.0, released on July 12, 2015, and the smallest permitted setting keeps roughly 550 MiB of recent blocks on disk. You still check every rule from the genesis block forward. You simply throw each block away once you have finished with it.

How it works

Pruning happens after validation, never instead of it.

A pruned node downloads the whole chain in order and verifies every signature, every fee and every rule exactly as an archival node does. What changes is the cleanup. Once a block's effects have been folded into the unspent output database, the raw block file and its undo file are removed from disk, oldest first. The verified result survives; the paperwork does not.

You choose the budget in mebibytes. Setting 550 is the floor and anything smaller is refused, because the software needs enough recent blocks on hand to handle a chain reorganization without redownloading. A value of 1 switches on manual mode, where nothing is deleted until you call the pruneblockchain command yourself.

The one number that does not shrink is the unspent output set. That database is the working state of the entire ledger, every coin currently spendable, and it grows with use rather than with time. Pruning does not touch it, which is why a pruned node still occupies several gigabytes rather than the 550 MiB in the setting.

Four things stop working. You cannot rescan a wallet for transactions older than your pruned depth, so importing an ancient seed phrase means resyncing from scratch. You cannot build a transaction index, which rules out running a block explorer or an Electrum server for other people. You cannot serve historic blocks to peers catching up, although BIP159 lets you advertise that you will serve the most recent 288 blocks, about two days' worth, and Bitcoin Core has signalled that since version 0.16.0. And going back to a full archive later means starting the download again.

Where you see it

Pruning is the default setting on almost every plug-and-play node box, and the reason a Raspberry Pi can do this job at all.

The arithmetic is the whole argument. A full archive passed 759 GB in August 2026 and keeps climbing, while a pruned node fits comfortably on the internal drive of a laptop you were going to throw out. For the overwhelming majority of people, who want to verify their own payments and stop leaking their addresses to a stranger's server, that is the entire requirement. Serving the network's history is a separate hobby with a separate budget.

The trap is the wallet. Prune first and import an old wallet second, and the node will refuse to look for your coins, because the blocks that contain them are gone. Set up the wallet before the pruning starts, or use a descriptor with a birth date that sits above your pruned depth.

Pruned node vs lightweight client

A pruned node and a lightweight client both fit on a small disk, and only one of them checked anything. A pruned node has personally verified every block since 2009 and simply declines to keep the receipts; its answer to "is this payment valid" comes from its own arithmetic. A lightweight client has verified nothing and asks a server, whose answer you accept because you have no way to test it. The similar footprint hides opposite trust models, and anyone choosing between them on storage grounds alone is comparing the wrong number.