This guide explains Bitcoin Core loadtxoutset RPC in plain English. It shows what the command does, what its result means and what it cannot prove.
TL;DR
- What it is: Bitcoin Core 26.0 introduced loadtxoutset for loading a serialized UTXO snapshot into a second chainstate. The snapshot-backed state can synchronise rapidly to the network tip while the original chainstate validates historical blocks in the background.
- Why it matters: loadtxoutset shortens time to a usable tip without skipping eventual historical validation. Operators should expose that distinction in monitoring and keep the background chainstate intact until validation is complete.
- Current position: Require a second reviewer and explicit rollback or expiry, and pause payments, signing or network-dependent services until post-change evidence is complete.
Bitcoin Core loadtxoutset RPC in simple English
Bitcoin Core loadtxoutset RPC: Core checks snapshot contents by hash against supported assumeUTXO bases. A third-party transport source need not be trusted, but the exact Core build and expected base still matter.
Simple example
A miner is checking Bitcoin Core loadtxoutset RPC. With pruning, two chainstates can exceed a small budget and Core 26 notes a practical minimum interaction.
Key terms in plain English
- Bitcoin Core:
- Widely used software that validates Bitcoin and can provide wallet, network and operator tools.
- RPC:
- A command that software sends to a node to request information or a local action.
- UTXO:
- An unspent transaction output: a piece of bitcoin that can be used as an input to a later transaction.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Snapshot path
A relative path is resolved under datadir; an absolute path is used directly. Stage files in a restricted location and prevent traversal or symlink substitution.
Supported base
Core checks snapshot contents by hash against supported assumeUTXO bases. A third-party transport source need not be trusted, but the exact Core build and expected base still matter.
Returned evidence
coins_loaded, tip_hash, base_height and absolute path identify what entered the second chainstate. Preserve them with the file hash and source record.
Dual chainstates
The snapshot state advances toward the network tip while the original chainstate performs full initial block download to the snapshot base. Both consume disk and cache resources.
Usable versus validated
Services can become current quickly, but that does not mean the snapshot has been justified by full history. Require getchainstates validated true under the documented completion policy.
Pruning
With pruning, two chainstates can exceed a small budget and Core 26 notes a practical minimum interaction. Reserve storage and monitor block and chainstate directories.
Failure recovery
Do not discard the snapshot, logs or original validation data prematurely. On failure, stop cleanly, record chainstate output and follow version-specific recovery documentation. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is the main point of Bitcoin Core loadtxoutset RPC?
Bitcoin Core loadtxoutset RPC: Core checks snapshot contents by hash against supported assumeUTXO bases. A third-party transport source need not be trusted, but the exact Core build and expected base still matter.
For Bitcoin Core loadtxoutset RPC, what should a beginner know about snapshot path?
A relative path is resolved under datadir. An absolute path is used directly.
For Bitcoin Core loadtxoutset RPC, what should a beginner know about supported base?
Core checks snapshot contents by hash against supported assumeUTXO bases. A third-party transport source need not be trusted, but the exact Core build and expected base still matter.
For Bitcoin Core loadtxoutset RPC, what should a beginner know about returned evidence?
coins_loaded, tip_hash, base_height and absolute path identify what entered the second chainstate.
Conclusion
loadtxoutset shortens time to a usable tip without skipping eventual historical validation. Operators should expose that distinction in monitoring and keep the background chainstate intact until validation is complete.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.