Bitcoin Core's fee estimator is about to stop wasting your sats | Bitcoin Index

Bitcoin Core has a fee estimation problem. When the mempool is quiet (like right now at 1-3 sat/vB), it still tells wallets to pay 10-20 sat/vB. You overpay, miners collect the difference, and there’s no refund.

This isn’t theoretical. Based on analysis in the PR discussion, the current estimator overestimates 44% of the time. That’s wasted sats on every payment, every Lightning channel close, every exchange withdrawal.

PR #34075 fixes this by adding a mempool-based estimator that looks at what’s happening right now, not what happened last week.

The backward-looking problem

Bitcoin Core’s current fee estimator (the Block Policy Estimator) watches confirmed transactions and builds a statistical model: “transactions at X sat/vB took Y blocks to confirm.”

This works fine when fee markets are stable. But when conditions change quickly, it lags. If fees drop overnight, the estimator still recommends yesterday’s rates because that’s all it knows.

Services worked around this years ago by switching to mempool.space’s API or building custom estimators. But Bitcoin Core, the reference implementation, kept recommending stale fees.

How mempool-based estimation works

The new estimator generates a block template (the same logic miners use) and calculates feerate percentiles from the top block’s worth of transactions.

Economical mode: 75th percentile of the template
Conservative mode: 50th percentile (median)

Then it compares that to the Block Policy Estimator’s suggestion and returns the lower of the two.

This design is conservative and non-gameable. Miners can’t manipulate estimates upward by spamming high-fee transactions into the mempool, because the old estimator acts as a ceiling. The mempool estimator only helps when fees are lower than historical data suggests.

Safeguards against bad mempool data

Not all nodes see the same mempool. A node with strict policy won’t see certain transactions. A node with loose policy might accept transactions the network rejects.

To prevent bad estimates, the PR tracks the last 6 blocks and compares mined transaction weight to mempool eviction weight. If the ratio is below 75%, the mempool estimator disables itself and falls back to the Block Policy Estimator alone.

This ensures the node’s mempool roughly matches the majority of hashrate’s view before trusting mempool data for fee estimates.

Why underestimation is safer than overestimation

The PR’s philosophy: it’s better to underestimate than overestimate.

Why? Because Bitcoin Core now has reliable fee-bumping tools:

RBF (Replace-By-Fee): rebroadcast with a higher fee
CPFP (Child-Pays-For-Parent): attach a high-fee child transaction
TRUC transactions: topologically restricted with guaranteed RBF
Ephemeral anchors: anyone-can-spend outputs for adding fees

If you underestimate and your transaction doesn’t confirm quickly, you can bump it. But if you overpay, that value is gone forever.

Performance: 73% success, 0% overestimation

Historical benchmarks show:

73% success rate (transaction confirms within target blocks)
0% overestimation (never pays more than necessary)
26% underestimation (transaction confirms slower than expected)

Compare this to the current Block Policy Estimator:

Higher success rate, but 44% overestimation

The 26% underestimation is the trade-off. In practice, when the mempool is empty the new estimator gives you a lower, accurate fee. When a fee spike happens, you might need to RBF.

Live benchmarks run at bitcoincorefeerate.com/stats.

How it compares to other estimators

mempool.space: Fully mempool-based, more responsive during spikes, but more susceptible to manipulation and no long-term estimates.

Bitcoin Augur (by Block): Mempool-based with predictive modeling. According to their benchmarks against an older Core version:

Provider	Miss Rate	Avg Overestimate	Total Difference
Augur	14.1%	15.9%	13.6%
Bitcoin Core v27.2	18.7%	44.2%	35.9%

Note: Core v27.2 is outdated. Recent improvements already reduced overestimation, and this PR would cut it further.

Bitcoin Core + this PR: Combines historical data and current mempool state, non-gameable, supports long-term estimates (up to 1008 blocks), safe defaults with automatic health checks.

Architecture changes

The PR refactors fee estimation to support multiple estimators:

FeeRateEstimatorBase: abstract class all estimators implement
FeeRateEstimatorManager: manages multiple estimators and selects the best result
CBlockPolicyEstimator: refactored Block Policy Estimator
CMempoolEstimator: new mempool-based estimator

This makes it easy to add future estimators (machine learning models, Lightning-aware estimators) without major refactoring.

Breaking changes

The PR changes wallet RPC output:

Before: fee_reason field (e.g., “ECONOMICAL”)
After: fee_source field (e.g., “block_policy”, “mempool”)

This is more semantically accurate (economical is a mode, not a source) but may break clients that parse fee_reason explicitly.

With verbosity level 3+, the RPC now exposes mempool health statistics showing whether the mempool estimator is active and reliable.

Who benefits

This matters most for:

Lightning node operators: channel closes and sweeps benefit from accurate low-fee estimates
Exchanges and services: batched withdrawals get cheaper without sacrificing reliability
Privacy-conscious users: consolidations and CoinJoins can use lower fees when the mempool is empty
Everyday wallet users: sendtoaddress stops wasting sats

Current status

As of March 16, 2026, the PR is open and actively reviewed. 31 commits, 1668 additions, 453 deletions across 54 files. It references issue #27995 opened by Pieter Wuille in 2023, which laid out the vision for mempool-based fee estimation.

Open questions include whether to eliminate time-based mempool expiration (to help censored transactions eventually confirm) and whether to add a “force block-policy-only” mode for users who want to explicitly disable mempool-based estimation.

Why this took so long

Bitcoin Core’s fee estimator has been overcharging users for years. Services routed around it since 2017. The PR author noted that most Core wallet users don’t even use the block-based estimator anymore because they’ve switched to external APIs. The existing estimator is too inaccurate.

This PR makes Bitcoin Core competitive with third-party services while maintaining the robustness and security guarantees the reference implementation is known for.

If merged, every wallet built on Bitcoin Core (and every Lightning node, exchange, and service) will stop overpaying when the mempool is quiet. That’s a meaningful UX improvement for the entire ecosystem.

Sources

Data/status as of March 16, 2026.