Bitcoin Core mempoolexpiry Explained: Transaction Retention

This guide explains Bitcoin Core mempoolexpiry in plain English. It focuses on what the subject is, why it matters and what a beginner should remember.

Local retention, not network truth

Each node maintains its own unconfirmed set under its own policy and uptime history. Expiry removes an entry locally after the configured age. It does not communicate cancellation and does not invalidate consensus-valid transactions. Payment systems must distinguish local absence from confirmed conflict, replacement or final business resolution.

How age interacts with pressure

Transactions can leave before the expiry horizon through block confirmation, conflict, replacement, reorganisation handling or memory-pressure eviction. A long expiry is not a guarantee of retention. Maxmempool and fee policy often dominate during congestion, while expiry matters most for old, otherwise acceptable entries.

Dependencies and packages

A parent transaction may support descendants. Removing or failing to retain part of a package changes what the node can validate and relay from its current mempool. Exact removal mechanics vary by version. Tests should include chains, replacements and conflicting spends rather than only standalone transactions.

Wallet expectations

Wallet interfaces may continue to show an unconfirmed transaction after the node’s mempool no longer contains it. Rebroadcast and abandonment behaviour is wallet- and version-specific. Operators must not automate a second payment merely because getmempoolentry fails; inspect wallet state, peers, conflicts and the chain first.

Mining and pool policy

A mining node cannot template a transaction absent from its local candidate set unless it receives it again. Short retention can reduce stale backlog but may discard packages valuable when fee conditions change. Primary and failover nodes should use intentional compatible policy or monitoring should explain why their templates differ.

Restart and persistence

Historical Core releases changed whether and how mempool contents survived restart. Expiry clocks and load-time checks can therefore behave differently across versions. Test graceful restart, crash recovery and an entry already older than the configured threshold. Never infer persistence from a modern node when documenting 0.12 behaviour.

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.

Conclusion

mempoolexpiry bounds local unconfirmed-state age; it does not erase a transaction from Bitcoin. Choose it with wallet and mining workflows in mind and test expiry, reappearance and restart explicitly.