Utreexo

Anna wants to send Peter bitcoin she received earlier. Her transaction therefore refers to that earlier payment. A separate record of an amount and the conditions for spending it is called an output; while unspent, it is a UTXO. An input in the new transaction contains a reference to that earlier output and the data needed to spend it. A node must check that the record really exists and Anna has not already spent it. Normally it maintains the UTXO set, a database of all currently unspent outputs, rather than personal accounts and balances. As it grows, disk work increases. Thaddeus Dryja introduced Utreexo in 2019 as a way to reduce this local burden. [1] [6] [8]

First, each record is hashed to produce a short fingerprint of its data. In a Merkle tree, fingerprints are paired and hashed again until a top fingerprint, the root, is reached. Utreexo uses several such trees; a validating node can keep their roots instead of the complete list. For Anna’s output it receives the data and a proof containing the necessary neighboring fingerprints. It recalculates the path to the root and compares the result with the state it already tracks. The sender’s assertion alone is therefore insufficient. This arrangement is called a cryptographic accumulator: it proves that a record belongs to a set. The roots are not a compressed backup, however. They cannot be unpacked to recover all the original records. [1] [2]

The supplied data are hashed, and the proof lets the node check their connection to the state it tracks. An invalid proof cannot simply be accepted because it came from a familiar server. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. A script is a set of conditions that must be met to spend an output. Even a valid membership proof does not replace checks of signatures, scripts, amounts and the other transaction and block rules. Utreexo changes state storage; it does not give permission to skip validation. [2] [5] [8]

Someone still has to retain enough data to construct proofs. The library documentation distinguishes a prover, which keeps the whole forest of trees, from a verifier, which needs only the roots. A verifier may cache some proofs, but roots alone cannot generate an arbitrary proof. The data have not disappeared; their distribution among participants changes. [2]

A block groups transactions into a batch added to the shared history. Spending removes an output from the tracked set, while new unspent outputs are added. Proofs change along with it. A proof saved for an earlier state may need updating before it can be used after subsequent blocks. In a reorganisation, the network adopts another valid branch of the chain, replacing part of its previous block history. An implementation must handle proof updates, concurrent transactions and rollback during a chain reorganization. This is not a certificate downloaded once and valid forever. [2] [3]

A Pruned Node discards old block data after validation but traditionally retains the current UTXO database. Utreexo targets that database. These are different savings that can be combined. Neither pruning nor a small accumulator, by itself, means a node verified the past without processing it. Block history, current state and the method of initial verification are three distinct things. [6] [5]

Imagine a new node starting from someone else’s account of the state instead of checking blocks from the beginning. It assumes that this starting state is correct. A small accumulator does not remove that trust: later proofs are checked against the accepted state. With AssumeUTXO, accepting a snapshot, a record of state at a particular time, is therefore separate from subsequent historical validation in the background. The utreexod documentation describes a default startup from state hardcoded in the program. That alone is not independent verification of all earlier blocks. How the node starts is a separate choice, not an inherent property of Utreexo. [7] [3]

The utreexod implementation uses Utreexo to validate the Bitcoin network. When checked on 17 October 2026, its documentation described it as beta and advised against using more than trivial amounts on mainnet. It also lists --noassumeutreexo to disable startup from assumed state. This is not an installation recommendation: before use, check the current version, mode, software source and recovery options. [3]

The basic design does not require rewriting Bitcoin’s monetary rules or changing existing blocks. Someone must still create, transmit and update proofs, so participating nodes need appropriate software and communication. Smaller local state can help cheaper devices. It does not automatically mean more transactions per block, lower fees for everyone or a switch of all nodes to a new format. [1] [4]

Less data on disk can mean more data over the network and dependence on timely availability. A correctly validating node rejects a forged proof. A provider can nevertheless withhold necessary data and delay validation. Operators therefore compare the whole setup: storage, transfer, cache, initial-state verification and outage behavior. Utreexo can make independent validation cheaper; it does not make missing data unimportant. [3] [4]