estimateSmartFee error: "Insufficient data or no feerate found"

ella-quicknode commented at 11:00 am on October 19, 2024: none

I am seeing a couple of issues been raised in the past. We currently experiencing the same issue. The work around was to delete fee_estimate.dat and mempool.dat from the node.

With regards to the below comment from issue 19150 (Originally posted by @maflcko in #19150 (comment)), I would like know what are the recommended config we can apply? Or is there a better way to manage this error?

0It is only possible to estimate fees when you have enough mempool transactions from the outside p2p network

If we encounter the error, after deleting the 2 dat files, the nodes will take some time to catch up and fetch new fee. I would like to check if there will be any alternative fee that user can manually calculate such as using minRelayTxFee ?

pinheadmz commented at 1:07 pm on October 19, 2024: member

Fee rate estimates are only available after the full node has monitored transactions entering the mempool and waiting for confirmation, over a long enough time span. I’m not sure what deleting those files would accomplish besides starting that process over. You can set a hard coded fee, or trust fee rates provide from some other source (like mempool.space)

ella-quicknode commented at 1:40 pm on October 19, 2024: none

Thanks for the reply @pinheadmz

We are seeing enough tx entering our infra consistently, but for some reason, the nodes occasionally returns this error Insufficient data or no feerate found, this error can’t be self subsided unless we manually delete the dat files, then nodes recovered for estmiateSmartFee.

I was just curious what’s the expected behaviour when we see error Insufficient data or no feerate found and how we can overcome this error without manually deleting the dat files . 🙂

pinheadmz commented at 1:52 pm on October 19, 2024: member

So the nodes return fee estimates as expected for some time, then just stop for some reason?

pinheadmz commented at 1:54 pm on October 19, 2024: member

It might be helpful to have version of the affected node and debug log output. You may need to run bitcoin-cli logging '["estimatefee"]' to add fee estimation log output. “mempool” may be helpful as well but could be spammy

laanwj added the label RPC/REST/ZMQ on Oct 20, 2024

qk-santi commented at 9:14 am on October 21, 2024: none

Hey @pinheadmz !

Thanks for answering

Since upgrading to v27 around April, we’ve been having estimation issues.

Right after upgrade to v27, we had incorrect estimations both on Testnet and Mainnet on all nodes.

On Mainnet, the estimates got stuck to ~300 sats for several days, while network was asking for ~50 sats. We waited a bit to check if mempool had to refresh and get newer transactions to get the pulse of the network, just in case if it had any improper batch of txs that were skewing the estimates.

We ended up deleting fee_estimate.dat and mempool.dat to get proper estimates again, which they came eventually after we had enough txs in the mempool again.

After that reset, Mainnet has been behaving correctly.

On the other hand on Testnet, after upgrade we got Insufficient data or no feerate found on all nodes. Which would be expected if mempool was running low on txs, but we were having 4-6k txs on the mempool at that time on the nodes. We also deleted fee_estimate.dat and mempool.dat and got back the estimates.

But on Testnet, that error has been coming back several times since then, while the mempool still has multiple thousand transactions, which should be enough to give an estimate.

pinheadmz commented at 1:03 pm on October 21, 2024: member

@qk-santi ok sounds like you have a clear understanding and the behavior is still unexpected. I would check two more things:

Check your bitcoin.conf for anything that might be affecting mempool policy (rbf, relayfee, whitelist, etc)
Enable estimate fee logging bitcoin-cli logging '["estimatefee"]' and watch debug.log for [estiamtefee] messages

estimateSmartFee error: “Insufficient data or no feerate found” #31116