AssumeUTXO - Revision history

NotATether: Add IBD context, Snapshot and validation, and Status sections

2026-09-13T07:34:41Z

Add IBD context, Snapshot and validation, and Status sections

← Older revision		Revision as of 07:34, 13 September 2026
Line 1:		Line 1:
	'''AssumeUTXO''' is a [[Bitcoin Core]] feature that lets a node load a serialized [[UTXO]] set snapshot at a predetermined height, then sync headers and blocks from that height to the tip while a background process reconstructs the UTXO set from genesis and checks that it matches the snapshot. The node can serve wallets sooner than a full initial block download, without permanently trusting the snapshot: divergence from the recomputed set is treated as a failure.		'''AssumeUTXO''' is a [[Bitcoin Core]] feature that lets a node load a serialized [[UTXO]] set snapshot at a predetermined height, then sync headers and blocks from that height to the tip while a background process reconstructs the UTXO set from genesis and checks that it matches the snapshot. The node can serve wallets sooner than a full initial block download, without permanently trusting the snapshot: divergence from the recomputed set is treated as a failure.

			== IBD context ==

	Initial block download validates every block from genesis and builds the UTXO set incrementally. On a typical connection this takes hours to days, dominated by script verification (unless assumevalid skips old scripts) and by disk writes to the chainstate. Pruning reduces disk for old blocks but does not shorten the time to a complete chainstate. AssumeUTXO, designed by James O'Beirne and others, treats a UTXO snapshot the way assumevalid treats historical scripts: a compiled-in hash of a particular height's chainstate is trusted temporarily. The snapshot is distributed out of band (file download). Mainnet parameters for height 840,000 were added in Bitcoin Core 28.0, enabling <code>loadtxoutset</code> on mainnet for a snapshot that matches that hash.		Initial block download validates every block from genesis and builds the UTXO set incrementally. On a typical connection this takes hours to days, dominated by script verification (unless assumevalid skips old scripts) and by disk writes to the chainstate. Pruning reduces disk for old blocks but does not shorten the time to a complete chainstate. AssumeUTXO, designed by James O'Beirne and others, treats a UTXO snapshot the way assumevalid treats historical scripts: a compiled-in hash of a particular height's chainstate is trusted temporarily. The snapshot is distributed out of band (file download). Mainnet parameters for height 840,000 were added in Bitcoin Core 28.0, enabling <code>loadtxoutset</code> on mainnet for a snapshot that matches that hash.

			== Snapshot and validation ==

	A snapshot is a serialization of the UTXO set at a snapshot height, content-hashed. Bitcoin Core ships the expected hash for one or more heights. The operator obtains a snapshot file from a source they consider available (another node, a published dump) and calls <code>loadtxoutset</code>. The node loads the snapshot into a secondary chainstate and checks its hash against the compiled-in value; syncs headers to the tip, then downloads and validates blocks after the snapshot height, updating the snapshot chainstate (script verification applies to those new blocks as usual); and in the background starts a full validation from genesis (or from an existing local chain) that rebuilds a chainstate independently. When background validation reaches the snapshot height, it compares the reconstructed UTXO set hash to the snapshot. A mismatch fails the node.		A snapshot is a serialization of the UTXO set at a snapshot height, content-hashed. Bitcoin Core ships the expected hash for one or more heights. The operator obtains a snapshot file from a source they consider available (another node, a published dump) and calls <code>loadtxoutset</code>. The node loads the snapshot into a secondary chainstate and checks its hash against the compiled-in value; syncs headers to the tip, then downloads and validates blocks after the snapshot height, updating the snapshot chainstate (script verification applies to those new blocks as usual); and in the background starts a full validation from genesis (or from an existing local chain) that rebuilds a chainstate independently. When background validation reaches the snapshot height, it compares the reconstructed UTXO set hash to the snapshot. A mismatch fails the node.
Line 11:		Line 15:
	Snapshot files are large because they contain the full UTXO set at the snapshot height. Operators usually download them from a published mirror or copy them from another node that already produced the dump. The compiled-in hash is the security boundary for that height. A corrupt or substituted file that fails the hash check is refused before the secondary chainstate is used.		Snapshot files are large because they contain the full UTXO set at the snapshot height. Operators usually download them from a published mirror or copy them from another node that already produced the dump. The compiled-in hash is the security boundary for that height. A corrupt or substituted file that fails the hash check is refused before the secondary chainstate is used.

	Background revalidation still downloads and verifies historical blocks, so disk and CPU costs are deferred rather than eliminated. Pruned nodes can use AssumeUTXO if they retain enough data for the background chainstate to complete, subject to Core's pruning rules. Future releases may ship hashes for newer snapshot heights as the chain grows past 840,000.		== Status ==

			Background revalidation still downloads and verifies historical blocks, so disk and CPU costs are deferred rather than eliminated. Pruned nodes can use AssumeUTXO if they retain enough data for the background chainstate to complete, subject to Core's pruning rules. Future releases may ship hashes for newer snapshot heights as the chain grows past 840,000. Operators should obtain snapshots from known mirrors and check the hash against Bitcoin Core's compiled-in value before calling <code>loadtxoutset</code>. A mismatched file is rejected, but a correct hash only proves agreement with that release's expected chainstate tip height.

	== See also ==		== See also ==

NotATether: Remove redlink See also target

2026-09-13T07:20:37Z

Remove redlink See also target

← Older revision		Revision as of 07:20, 13 September 2026
Line 18:		Line 18:
	* [[Full node]]		* [[Full node]]
	* [[Utreexo]]		* [[Utreexo]]
	* [[Pruned node]]

	== External links ==		== External links ==

NotATether: Expand See also links

2026-09-13T07:20:08Z

Expand See also links

← Older revision		Revision as of 07:20, 13 September 2026
Line 18:		Line 18:
	* [[Full node]]		* [[Full node]]
	* [[Utreexo]]		* [[Utreexo]]
			* [[Pruned node]]

	== External links ==		== External links ==

NotATether: Add revalidation cost and future snapshots

2026-09-13T07:20:06Z

Add revalidation cost and future snapshots

← Older revision		Revision as of 07:20, 13 September 2026
Line 10:		Line 10:

	Snapshot files are large because they contain the full UTXO set at the snapshot height. Operators usually download them from a published mirror or copy them from another node that already produced the dump. The compiled-in hash is the security boundary for that height. A corrupt or substituted file that fails the hash check is refused before the secondary chainstate is used.		Snapshot files are large because they contain the full UTXO set at the snapshot height. Operators usually download them from a published mirror or copy them from another node that already produced the dump. The compiled-in hash is the security boundary for that height. A corrupt or substituted file that fails the hash check is refused before the secondary chainstate is used.

			Background revalidation still downloads and verifies historical blocks, so disk and CPU costs are deferred rather than eliminated. Pruned nodes can use AssumeUTXO if they retain enough data for the background chainstate to complete, subject to Core's pruning rules. Future releases may ship hashes for newer snapshot heights as the chain grows past 840,000.

	== See also ==		== See also ==

NotATether: Add snapshot distribution and hash check

2026-09-13T07:20:04Z

Add snapshot distribution and hash check

← Older revision		Revision as of 07:20, 13 September 2026
Line 8:		Line 8:

	Bitcoin Core is the implementation. Experimental support appeared in earlier major versions; 28.0 added mainnet snapshot parameters at height 840,000. Other node software may have analogous snapshot-import tools that are not called AssumeUTXO and may not revalidate in the background. Related approaches to reducing [[Full node\|full node]] resource costs include [[Utreexo]].		Bitcoin Core is the implementation. Experimental support appeared in earlier major versions; 28.0 added mainnet snapshot parameters at height 840,000. Other node software may have analogous snapshot-import tools that are not called AssumeUTXO and may not revalidate in the background. Related approaches to reducing [[Full node\|full node]] resource costs include [[Utreexo]].

			Snapshot files are large because they contain the full UTXO set at the snapshot height. Operators usually download them from a published mirror or copy them from another node that already produced the dump. The compiled-in hash is the security boundary for that height. A corrupt or substituted file that fails the hash check is refused before the secondary chainstate is used.

	== See also ==		== See also ==

NotATether: Create AssumeUTXO stub: UTXO snapshot + background revalidation; Bitcoin Core 28.0 mainnet height 840000; link UTXO/Bitcoin Core/Full node/Utreexo

2026-09-12T19:46:51Z

Create AssumeUTXO stub: UTXO snapshot + background revalidation; Bitcoin Core 28.0 mainnet height 840000; link UTXO/Bitcoin Core/Full node/Utreexo

New page

'''AssumeUTXO''' is a [[Bitcoin Core]] feature that lets a node load a serialized [[UTXO]] set snapshot at a predetermined height, then sync headers and blocks from that height to the tip while a background process reconstructs the UTXO set from genesis and checks that it matches the snapshot. The node can serve wallets sooner than a full initial block download, without permanently trusting the snapshot: divergence from the recomputed set is treated as a failure.

Initial block download validates every block from genesis and builds the UTXO set incrementally. On a typical connection this takes hours to days, dominated by script verification (unless assumevalid skips old scripts) and by disk writes to the chainstate. Pruning reduces disk for old blocks but does not shorten the time to a complete chainstate. AssumeUTXO, designed by James O'Beirne and others, treats a UTXO snapshot the way assumevalid treats historical scripts: a compiled-in hash of a particular height's chainstate is trusted temporarily. The snapshot is distributed out of band (file download). Mainnet parameters for height 840,000 were added in Bitcoin Core 28.0, enabling <code>loadtxoutset</code> on mainnet for a snapshot that matches that hash.

A snapshot is a serialization of the UTXO set at a snapshot height, content-hashed. Bitcoin Core ships the expected hash for one or more heights. The operator obtains a snapshot file from a source they consider available (another node, a published dump) and calls <code>loadtxoutset</code>. The node loads the snapshot into a secondary chainstate and checks its hash against the compiled-in value; syncs headers to the tip, then downloads and validates blocks after the snapshot height, updating the snapshot chainstate (script verification applies to those new blocks as usual); and in the background starts a full validation from genesis (or from an existing local chain) that rebuilds a chainstate independently. When background validation reaches the snapshot height, it compares the reconstructed UTXO set hash to the snapshot. A mismatch fails the node.

Until background validation completes, the node is relying on AssumeUTXO for the state at the snapshot height. Peers and wallets can use the node for recent payments. Mining and other operations that require a fully validated history may be restricted until the background check finishes. Snapshots must correspond to a block on the most-work chain that the node later sees. The feature does not replace checkpoints for header validity; it only compresses the wait for a usable UTXO set.

Bitcoin Core is the implementation. Experimental support appeared in earlier major versions; 28.0 added mainnet snapshot parameters at height 840,000. Other node software may have analogous snapshot-import tools that are not called AssumeUTXO and may not revalidate in the background. Related approaches to reducing [[Full node|full node]] resource costs include [[Utreexo]].

== See also ==
* [[UTXO]]
* [[Bitcoin Core]]
* [[Full node]]
* [[Utreexo]]

== External links ==
* [https://bitcoinops.org/en/topics/assumeutxo/ Bitcoin Optech: AssumeUTXO]
* [https://github.com/bitcoin/bitcoin/blob/master/doc/assumeutxo.md Bitcoin Core AssumeUTXO documentation]
* [https://bitcoincore.org/en/releases/28.0/ Bitcoin Core 28.0 release notes]

[[Category:Technical]]