The kilobyte UTXO set

Core keeps the UTXO set in a LevelDB database (chainstate/, ~48 bytes per coin plus index overhead) fronted by an in-memory cache (-dbcache, default 450 MiB). While the working set fits in the cache, coin lookups and updates are memory-speed. When the cache fills during sync, Core writes it out and empties it — so the next few million lookups all miss and go to disk.

With ~170M coins needing north of 10 GB of cache, a default-sized cache overflows constantly. Every miss is a random read; every flush rewrites overlapping LevelDB files (compaction). On a machine with 2–4 GB of RAM this — not hashing, not signatures — is where initial sync goes to die. The standard advice "raise your dbcache" is a workaround for exactly the cost accumulators remove.

assumeutxo lets a node start from a UTXO snapshot and validate history in the background — a big usability win. But the snapshot is the 12 GB state: you still have to download it, hash it, store it, and random-access it forever after. It moves the state problem around the timeline; it doesn't shrink the state. An accumulator shrinks the thing itself, which is why the two compose nicely: an accumulator checkpoint is a kilobyte you can read in a code review.

Empirically, a large share of outputs are spent within hours or days of creation (change outputs, exchange churn, batching flows). Utreexo exploits this: nodes keep recently added leaves cached, and peers skip sending proofs for anything the receiver is known to cache. Since most spends hit young coins, most proofs shrink to nearly nothing. The published numbers span exactly this effect: proofs roughly double a block uncached, utreexod ships at about ×1.7, and the paper's simulated 500 MB leaf cache brings the whole download down to about ×1.25. The long-tail — old coins waking up — pays full ~28-hash fare.

A full sync is bounded below by max(network, disk, cpu). On mid-2026 mainnet (~753 GB of blocks, ~3B inputs): a 1 Gbps line needs ~1h40m for the download no matter what; hashing and parsing cost tens of minutes of CPU; signatures below assumevalid are skipped. On big-RAM hardware the UTXO term is small — so Utreexo barely moves the bound there, and the extra proof bytes actually raise the network term.

The transformation is on constrained hardware: with 2 GB of RAM, a stock node's UTXO term explodes into billions of disk seeks (days), while a Utreexo node's stays exactly where the big-RAM one is. Accumulators don't lower the floor — they make the floor reachable on hardware that used to sit 10× above it.

Think of the aggregate as a ledger that must balance. Every hint-0 output deposits H(outpoint) exactly once when it's created; every input withdraws H(outpoint) exactly once when it spends. If history is honest, deposits and withdrawals pair off perfectly and the balance is zero.

Now try to cheat. Spend a coin that never existed: a withdrawal with no matching deposit — non-zero. Spend the same coin twice: two withdrawals, one deposit — non-zero. Mark a doomed output as “unspent” in the hints: its deposit never happens but its withdrawal does — non-zero. Mark a surviving output as “doomed”: a deposit nobody withdraws — non-zero. The hash makes collisions infeasible, so entries can't be forged to cancel accidentally. One equality at the end certifies billions of set operations that were never performed individually.

Fuller designs fold amounts into the aggregated data to tighten the money-supply check; the gist walks the exact accounting.

The hints are not an authority — they're foreknowledge: claims about the future ("this output will die before the tip") that let the node skip building a searchable database. Foreknowledge is checkable after the fact, and every bit is checked — just not at the moment it's read. All the checks are batched into the single zero-equality at the end; the four ways a hint or a block could lie each leave the sum non-zero (see the drawer above).

Two hardening details close the remaining gaps. First, each node salts the hash with its own random secret, so an adversary who authors both hints and transactions can't precompute entries engineered to cancel (this blocks Wagner-style attacks on additive aggregates). Second, hints are deterministic given the chain and target height — anyone can regenerate the file and compare, so a published hint file is reproducible, not bespoke.

The result: wrong hints have exactly one power — making the final equation fail, at which point the node discards the attempt and fetches hints elsewhere. The failure mode is wasted hours, never a wrong UTXO set. That's the pattern all of these designs share (Utreexo proofs, SwiftSync hints, assumeutxo snapshots): convert trust into deferred verification, and make every failure fail closed. Untrusted helpers may make you slow; they may never make you wrong. The honest residue is the same as today's node: the reviewable constants in the source (assumevalid, snapshot hashes) and the code itself.

They compose, too: a Utreexo node can use SwiftSync-style hints to skip proof verification for coins that die during sync — the ideas attack orthogonal costs (state vs. seriality).

RSA accumulators (Boneh–Bünz–Fisch, 2019) commit a set into a single group element; membership proofs are constant-size and don't go stale the way Merkle paths do, and thousands of proofs aggregate into one. The catch: you need a modulus nobody can factor — a trusted setup ceremony, anathema to Bitcoin's assumptions. Class groups avoid the ceremony but make every operation orders of magnitude slower. Merkle forests won in practice because they're plain SHA-2 hashing (SHA-512/256 in the shipped code): no new assumptions, fast on any CPU, auditable by anyone who can read forty lines of code.

The pieces: an embeddable compact-state node (Floresta ships as a library with bindings for exactly this), a hardcoded accumulator checkpoint — a kilobyte of roots, reviewable in the source like assumevalid — and forward-only validation from that checkpoint: headers, then blocks with proofs, a few thousand blocks rather than history. Wallet discovery uses compact block filters (BIP 158) checked locally, so no server ever learns your addresses.

The honest costs: proof-carrying blocks are ~×1.7 bytes on a possibly metered connection, and sustained hashing costs battery — so the realistic mode is "validate on Wi-Fi and charge, serve the wallet locally all day," not always-on validation. The trust model is the desktop one: your own hashes plus a reviewable constant.

To be precise about what this improves on: today's light wallets are not "no validation." An SPV client verifies the header chain (proof-of-work, difficulty) and Merkle inclusion of its transactions, so a server cannot forge a payment to it — and Neutrino (BIP 157/158) already fixed the privacy leak that Electrum-style and bloom-filter wallets have. What no light client can do is check rule-validity: scripts, signatures, inflation, double-spends elsewhere. It follows the most-work chain unconditionally, trusting the hashrate majority to enforce the rules, and it can be lied to by omission. That specific gap — enforcing consensus rules yourself — is the one a checkpointed Utreexo node closes; privacy it merely matches.

Further out on the same road: consensus-committed UTXO roots would remove even the checkpoint constant, and ZeroSync-style chain proofs would replace catching-up with downloading a proof — but those need a soft fork and maturing proof systems respectively. Utreexo-from-checkpoint needs neither.

Miners race the network: every millisecond spent validating a fresh block delays mining on top of it, which costs real revenue in stale and empty blocks. They keep the whole UTXO set pinned in RAM and want the block-relay hot path as thin as possible — attaching and verifying proofs there is a cost with no compensating benefit for them.

Exchanges, explorers, and API providers need address indexes, transaction history, and mempool analytics — orders of magnitude more state than the UTXO set — so shrinking the UTXO set saves them approximately nothing. But they own the beefy hardware anyway, which makes them the natural bridge operators: maintaining the full forest and serving proofs is a service role that fits infrastructure budgets.

This split isn't a failure of adoption — it's the intended shape: few fat provers, many thin verifiers. The asymmetry between a data-center bridge and a phone verifying against 28 hashes is precisely what the accumulator was designed to create.