Bitcoin Core maxmempool Explained: Limits and Eviction

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

What the limit covers

The setting bounds the mempool data structure used for unconfirmed transactions, measured with release-specific accounting. It does not cap total bitcoind resident memory. Peer buffers, validation caches, wallet state, indexes, RPC responses and the operating system page cache remain separate. Capacity planning must compare observed RSS and cgroup limits, not equate the argument with process size.

Package-aware eviction

Transactions can depend on unconfirmed parents. Evicting a single low-fee parent can make descendants unusable, so Core evaluates packages and removes related entries. The exact ancestor and descendant logic evolved. An operator should test realistic chains rather than assume every transaction competes independently on its own feerate.

Rolling minimum fee

After eviction the node raises its effective mempool minimum above the removed package and later decays that threshold. This local policy reduces immediate re-entry and repeated churn. Two honest nodes with different memory pressure can therefore accept different transactions while agreeing completely on consensus-valid blocks.

Mining and template effects

A pool node can only select transactions it has retained or can reacquire. A small mempool may discard low-fee packages that later become attractive through descendants, while an oversized pool can compete with template construction and validation for memory. Measure template latency, stale work and package availability on primary and failover nodes.

Interaction with other fees

maxmempool works with incremental relay fee, minimum relay fee, replacement rules and transaction expiry. Those controls answer different questions. The memory cap triggers eviction; relay thresholds govern admission; replacement pricing discourages bandwidth churn; expiry removes old entries. Treating one as a substitute for the others creates surprising policy.

Monitoring the effective state

Use getmempoolinfo fields appropriate to the installed release, alongside RSS, swap, allocator behaviour and eviction-related logs. Watch bytes, usage, transaction count and mempool minimum rather than one dashboard number. Alert on sustained pressure and on divergence between nodes that should provide equivalent mining or wallet service.

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

maxmempool is a resource-control and relay-policy input, not a consensus rule. Size it from measured workload and total memory headroom, then verify eviction, mining and failover behaviour under deliberate pressure.