Understand the different jobs of Bitcoin Core’s block files, UTXO database, undo records and indexes before planning storage or recovery.
A node keeps several kinds of information
“The blockchain database” is a convenient phrase, but it hides several distinct jobs. A node needs historical block content, a way to find blocks, the current set of spendable outputs and enough information to handle recent chain changes. A wallet has another job: tracking a particular collection of scripts and, where applicable, protecting signing keys.
These records overlap in purpose without being interchangeable. A healthy current UTXO database does not mean every old transaction can be fetched instantly. A folder of blocks does not constitute a backup of private wallet keys.
Separate content from current state
Core stores block data in numbered blk files, block-disconnection information in numbered rev files, and UTXO state in chainstate. A block index helps organize known blocks. Optional indexes support additional queries rather than changing the consensus meaning of a payment.
Treat these names as versioned implementation details. Modern releases can apply a rolling XOR pattern to block and undo files. A home-made reader that assumes every byte is plain network-format data at a guessed offset can fail even when the node itself reads its files successfully.
Why undo data exists
Connecting a block consumes previous outputs and creates new ones. If a reorganization disconnects that block, the node must reverse those effects. The block contains the new transactions, but it does not contain every detail of every previously spent output. Undo information supports restoring that prior state.
Follow one output through a reorganization
Before a block, a 40,000-sat output is unspent. The block spends it and creates replacement outputs. When that block is disconnected, those new outputs must disappear from the active UTXO state and the original coin must be restored. Merely deleting the new block's transactions from an explorer table is not enough to repair a node's spendable state.
Rebuildable does not mean free to delete
Some node records can be rebuilt from sufficient block data, but rebuilding takes time, I/O and sometimes substantial redownloading. A missing optional index calls for different recovery steps from a damaged wallet backup. Never use a storage lesson as an instruction to remove files from a running node.
Before recovery, identify the failing component, software version, available backups and retention policy. Preserve irreplaceable wallet material separately. Use documented tools and a controlled stop where required. Guessing which directory looks largest can turn a performance issue into an extended outage.
Plan capacity around the workload
A validating node, public explorer and full-history reporting service have different storage needs. Pruning can reduce retained block data while keeping validation capability, but it limits locally available historical scans. An address index introduces its own space and rebuild cost.
For an explorer, measure block storage, index storage, permanent account data and temporary exports separately. Expiring a report file should not delete its underlying chain evidence or a customer's payment record. Clearly separating those lifetimes makes storage estimates and incident recovery much easier to reason about.
Sources and further reading
Key takeaways
- Historical blocks, current UTXO state, undo information and wallets have different purposes.
- Undo records support reversing block effects during chain changes.
- Capacity and recovery plans must distinguish rebuildable indexes from irreplaceable wallet material.
Common questions
Does chainstate contain every old transaction?
No. Its main job is representing current unspent outputs and associated state, not offering a complete transaction archive.
Can I free space by deleting large node folders?
Do not delete arbitrary node files. Use supported retention settings and documented recovery procedures for the installed version.