BA-09 · LESSON 05

Pruning and assumeutxo

KEY DEFINITIONS

Terms used in this lesson

UTXO: Unspent transaction output: one discrete chunk of bitcoin that can be used as a transaction input.

Resource-saving modes change storage or bootstrap work without replacing final validation guarantees.

35 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · p2p propagationIndependent peers relay claims, then verify locallySelect any state to inspect its exact role.

RELATIONSHIP MAPIndependent peer relationships

01
ORIGINWallet or peer
A node receives a transaction, header, block, or request from an untrusted connection.
02
PARSEBounded message
Length, command, encoding, and resource limits are checked before deeper work.
03
VALIDATEPruning and assumeutxo
The Pruning and assumeutxo stage applies local policy or consensus rules as appropriate.
04
STOREMempool or chainstate
Accepted data enters a local view that can differ temporarily from another node's view.
05
RELAYSelected peers
Relay spreads a valid candidate; it does not make the candidate final or universally known.

Rule shown: Network messages are invitations to verify, never authority to accept state.

STAGE 1 OF 5ORIGIN: Wallet or peer

A node receives a transaction, header, block, or request from an untrusted connection.

Governing relationship: Network messages are invitations to verify, never authority to accept state. Complete path: 1. ORIGIN, Wallet or peer. A node receives a transaction, header, block, or request from an untrusted connection. 2. PARSE, Bounded message. Length, command, encoding, and resource limits are checked before deeper work. 3. VALIDATE, Pruning and assumeutxo. The Pruning and assumeutxo stage applies local policy or consensus rules as appropriate. 4. STORE, Mempool or chainstate. Accepted data enters a local view that can differ temporarily from another node's view. 5. RELAY, Selected peers. Relay spreads a valid candidate; it does not make the candidate final or universally known.

1. State transitionWhat exists, what changes, and what results

BEFORE

Node P has already validated to height H and prunes old blocks. Node S starts from a recognized AssumeUTXO snapshot at height H.

MECHANISM

A node downloads and validates blocks, builds chainstate, then may delete sufficiently old block files under configured storage limits.

AFTER

Pruning changes retained history; AssumeUTXO changes bootstrap scheduling. Neither changes the consensus rules applied to new blocks.

Text equivalent: Starting from Node P has already validated to height H and prunes old blocks. Node S starts from a recognized AssumeUTXO snapshot at height H. The mechanism begins when A node downloads and validates blocks, builds chainstate, then may delete sufficiently old block files under configured storage limits. The resulting lesson is Pruning changes retained history; AssumeUTXO changes bootstrap scheduling. Neither changes the consensus rules applied to new blocks.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Validate before pruning

A node downloads and validates blocks, builds chainstate, then may delete sufficiently old block files under configured storage limits.

Complete path: 1. Validate before pruning: A node downloads and validates blocks, builds chainstate, then may delete sufficiently old block files under configured storage limits. 2. Retain active state: Pruning keeps the current UTXO set, block index, and recent files needed for reorg handling and ongoing validation. 3. Load a recognized snapshot: AssumeUTXO-capable software recognizes metadata and a commitment for a snapshot at a specific chain height rather than trusting any arbitrary file. 4. Advance snapshot chainstate: The node can validate new blocks from that state while a separate background chainstate validates history from genesis. 5. Complete background validation: Historical validation recomputes the snapshot boundary. A mismatch is a failure; the snapshot is not a permanent substitute for verification.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Pruning occurs only after validation, while a snapshot needs recognized metadata, exact commitment match, and eventual genesis-to-boundary background validation.

CHANGED CONDITION

An unknown or mismatched snapshot is unusable, and a pruned node cannot satisfy a rescan below retained history without obtaining old blocks again.

Important distinction: A pruned node trusts another server's UTXO balances because it deleted old blocks. It built chainstate by validating those blocks before deletion. Its limitation is historical data service and rescanning, not current consensus validation.

Text equivalent: The accepted path is enforced by Pruning occurs only after validation, while a snapshot needs recognized metadata, exact commitment match, and eventual genesis-to-boundary background validation. If the required condition changes, An unknown or mismatched snapshot is unusable, and a pruned node cannot satisfy a rescan below retained history without obtaining old blocks again.

Loading lesson visuals...

Learn the idea

Pruning deletes old raw block and undo files after validation while retaining chainstate and enough recent data for safe operation. A pruned node still validates the chain itself but cannot serve all historical blocks. AssumeUTXO is a bootstrap design that can load a hash-committed UTXO snapshot at a specified height, continue forward operation, and validate historical blocks in the background before treating the snapshot as fully validated.

GUIDED EXPLANATION1/5 ideas inspected

Validate before pruning

A node downloads and validates blocks, builds chainstate, then may delete sufficiently old block files under configured storage limits.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A pruned node trusts another server's UTXO balances because it deleted old blocks.”

It built chainstate by validating those blocks before deletion. Its limitation is historical data service and rescanning, not current consensus validation.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.