The only problem is that mempool size is so small by default that it quickly gets filled by a random burst of activity. Increasing mempool size would fix this, there’s an open issue: Default Dynamic Size Limit Too Low (Default mempool of 320MB/serialized mempool of 100MB) (#518) · Issues · Bitcoin Cash Node / Bitcoin Cash Node · GitLab
and the faster blocks CHIPs recommends a change in that: readme.md · master · ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab
Of economic worth, yeah. But “days destroyed” works as anti-DoS measure, too. And cleaning up dust is good for the network so we could still discount some inputs based on UTXO age (“days destroyed”): Lower the default relay fee, create a fee estimation algorithm - #105 by bitcoincashautist
This is fixable, we can use difficulty to automatically update the fee floor: Research: Block difficulty as a price oracle
But this is orthogonal to the rolling fee algorithm, which increases it above the floor in response to usage (not price), and later decays back to floor.
We literally already have elastic relay fee floor, and it needs not care about block fullness. Why should it? If blocks get full and more transactions keep coming in, mempool will grow and algo will respond to that. If blocks are full but it so happens that there’s just enough to keep blocks full but mempool clear, why should the fee rise? There’s no need to rise it when situation is just below the tipping point.
Here’s how the current algo works (Introduced back in 2016, Bitcoin Core v0.12):
How Bitcoin’s Mempool Fee Decay Algorithm Works
When the mempool fills up and overflows, nodes need to decide which transactions to keep and which to throw away. Here’s how it works:
Eviction
When mempool exceeds its size limit, the lowest fee rate transactions get evicted. If multiple transactions have the same fee rate, the newest one (most recently seen) gets evicted first. If there’s still a tie, the transaction hash is used as a final tie-breaker.
Fee Bump
When a transaction is evicted, the minimum relay fee is raised to match the evicted transaction’s fee rate (plus a small increment). This prevents the same transaction from immediately re-entering.
Decay
The raised fee doesn’t stay elevated forever. It decays exponentially back toward the floor value using a halflife formula:
new_rate = old_rate / 2^(elapsed_time / halflife)
The base halflife is 12 hours, but it accelerates as the mempool empties:
| Mempool Usage |
Halflife |
| >= 50% full |
12 hours |
| 25-50% full |
6 hours |
| < 25% full |
3 hours |
When Does Decay Happen?
Here’s a subtle detail: decay only advances after a block is mined. The algorithm checks if at least 10 seconds have passed since the last update, then calculates the decay based on actual elapsed time. But if no block has arrived since the last fee bump, decay is paused entirely.
This means with 10-minute blocks, a 40-minute outlier block (which happens ~5% of the time) can delay fee recovery by 40 minutes. With faster blocks, the decay responds more consistently.
Floor Value
Once the fee rate decays below half of the minimum reasonable relay fee, it snaps to the floor value. Internally it’s stored as zero (to skip further decay calculations), but the returned fee is always at least the minimum reasonable relay fee.
