Mempool Based Fee Estimation on Bitcoin Core

Implementation
4

Thank you for the link I find the ideas very insightful

we can simply choose a feerate that is min(confirmed_estimate,mempool_estimate)

The issue with the approach you mentioned is that we will be adapting downwards towards lower estimates, especially in cases where previously mined blocks have lower fee rate. Instead of adapting to the current mempool state, we will be providing a low fee rate estimate.

I try modifying the current data to give provide min(confirmed_estimate,mempool_estimate).

It is underestimating as expected, this will prevent the current overestimating of CBlockPolicyEstimator but the problem of underestimation will still be relevant.

Mempool fee estimate vs estimatesmartfee vs Actual block median fee(1)
Mempool fee estimate vs estimatesmartfee vs Actual block median fee(1)1014×627 63.4 KB

Fee Estimation data with threshold - Google Sheets

mempool_estimate is based on mempool stats like you describe (which has the risk of potentially being gameable and might also break accidentally, such as after a soft fork).

I believe the checks we will have in place could prevent a node from using this estimation mode in the case of soft forks. One scenario where miners could manipulate the mempool and cause congestion is by mining empty blocks or deliberately refraining from mining for some time to congest the mempool and make fee estimate spike up. However, assuming mining is decentralized, this scenario will not hold? Are their other instances ?