# Block files, chainstate and undo data

Understand the different jobs of Bitcoin Core’s block files, UTXO database, undo records and indexes before planning storage or recovery.

Canonical page: https://mybitcoinexplorer.com/learn/block-files-chainstate-and-undo
Topic: Nodes and the network
Published: 2026-10-31
Updated: 2026-10-31

> Implementation examples refer to Bitcoin Core 30.0. File layouts and operational behavior can change; check the documentation for your installed version.

## 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.

> Diagram: Storage supports different questions — Block files: historical content → Validation: apply transactions → Chainstate: unspent outputs → Undo records: reverse a connection

## 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.

### Worked example: 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.

## 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.

## Sources and further reading

- [Core 30.0: filesystem layout](https://github.com/bitcoin/bitcoin/blob/v30.0/doc/files.md)
- [Core 30.0: block connection and disconnection](https://github.com/bitcoin/bitcoin/blob/v30.0/src/validation.cpp)

## Related lessons

- [Full nodes vs pruned nodes](https://mybitcoinexplorer.com/learn/full-vs-pruned-nodes)
- [Transaction indexes versus address-history indexes](https://mybitcoinexplorer.com/learn/txindex-and-address-index)
- [Stale blocks and chain reorganizations](https://mybitcoinexplorer.com/learn/stale-blocks-and-reorgs)