This guide explains Bitcoin Core mempool persistence in plain English. It focuses on what the subject is, why it matters and what a beginner should remember.
TL;DR
- What it is: Bitcoin Core 0.14 introduced retention of the mempool across restarts by writing mempool.dat before shutdown and loading it on startup. This avoided rebuilding the local transaction view solely from new announcements and preserved prioritisation changes.
- Why it matters: Mempool persistence accelerates recovery of useful local transaction state, but every entry remains subject to current chain and policy. Operate mempool.dat as version-specific, sensitive and disposable state with tested corruption handling.
- Current position: Bitcoin Core 0.14 introduced retention of the mempool across restarts by writing mempool.
Bitcoin Core mempool persistence in simple English
Bitcoin Core mempool persistence: The file records mempool transactions and relevant metadata so Core can attempt to restore them after restart. Core 0.14 also preserved changes made with prioritisetransaction.
Simple example
A miner is checking Bitcoin Core mempool persistence. Check the exact release notes before upgrade or downgrade and allow the node to rebuild from the network when compatibility is uncertain.
Key terms in plain English
- Bitcoin Core:
- Widely used software that validates Bitcoin and can provide wallet, network and operator tools.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Mempool:
- A node’s changing local collection of valid, unconfirmed transactions.
- 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.
What is persisted
The file records mempool transactions and relevant metadata so Core can attempt to restore them after restart. Core 0.14 also preserved changes made with prioritisetransaction. It does not store confirmations, create wallet backups or override current consensus and policy checks during load.
Startup revalidation
Transactions loaded from disk must still be checked against the current UTXO set, conflicts, expiry, fee policy and memory limits. Blocks received while the node was offline may have confirmed or conflicted entries. A loaded count below the saved count can be healthy and should be explained by rejection evidence.
Shutdown and crash behaviour
The normal path writes the file before shutdown. A crash, full disk or interrupted rename can leave no current snapshot or a damaged file. Operators must not extend shutdown timeouts blindly or kill a node during the dump. Test both graceful and forced termination on disposable state.
Security and trust boundary
mempool.dat is untrusted operational input at startup and may contain transactions that reveal local observation or prioritisation. Protect data-directory permissions and never copy a production file into a support ticket. Parser and resource limits matter even though transaction consensus checks still apply.
Mining implications
A restarted pool node can rebuild templates sooner from retained candidates, including local priority adjustments in the original design. Primary and failover nodes may have different snapshots and policy. Compare template fees, packages and reconstruction state rather than assuming identical mempools are required for correctness.
Version and format compatibility
Core 0.14 introduced automatic persistence, 0.15 exposed a configuration switch and much later releases changed formats. A file is not a stable cross-version interchange API. Check the exact release notes before upgrade or downgrade and allow the node to rebuild from the network when compatibility is uncertain.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is the main point of Bitcoin Core mempool persistence?
Bitcoin Core mempool persistence: The file records mempool transactions and relevant metadata so Core can attempt to restore them after restart.
For Bitcoin Core mempool persistence, what should a beginner know about what is persisted?
The file records mempool transactions and relevant metadata so Core can attempt to restore them after restart.
For Bitcoin Core mempool persistence, what should a beginner know about startup revalidation?
Transactions loaded from disk must still be checked against the current UTXO set, conflicts, expiry, fee policy and memory limits.
For Bitcoin Core mempool persistence, what should a beginner know about shutdown and crash behaviour?
The normal path writes the file before shutdown. A crash, full disk or interrupted rename can leave no current snapshot or a damaged file.
Conclusion
Mempool persistence accelerates recovery of useful local transaction state, but every entry remains subject to current chain and policy. Operate mempool.dat as version-specific, sensitive and disposable state with tested corruption handling.
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.