1

Around block 564815 (2019-02-26 23:40 UTC), the mempool was empty. I noticed that my two nodes are giving very different estimates for transaction fees to be used:

Node 1

  • Version: 17.1.0
  • Number of peers: 21
  • Synched for: about three weeks
  • Prunned: 3GB
// see how many transactions are there in the mempool
 >bitcoin-cli getrawmempool | wc -l 
 4027

>bitcoin-cli estimatesmartfee 5 {
    “feerate”: 0.00021195,
    “blocks”: 5 }

>bitcoin-cli estimatesmartfee 5 ECONOMICAL {
    “feerate”: 0.00009715,
    “blocks”: 5 }

Node 2

  • Version: Bitcoin core 17.0.0
  • Number of peers: 8
  • Synched for: about 5 hours
  • Prunned: 3GB
# see how many transactions are there in the mempool
>bitcoin-cli getrawmempool | wc -l
3999

>bitcoin-cli estimatesmartfee 5
{
    “feerate”: 0.00008823,
    “blocks”: 5
}

>bitcoin-cli estimatesmartfee 5 ECONOMICAL
{
    “feerate”: 0.00001000,
    “blocks”: 5
}

The node that has been synchronized for only 5 hours and is less well connected seems to be estimating the fee better than the one that has been synchronized for three weeks. Why is the "best" node the one that gives the worst fee? Why are the fee estimates so different and what can be done to make them more accurate?

Improve this question

1 Answer 1

Reset to default
2

The node that has been synchronized for only 5 hours and is less well connected seems to be estimating the fee better than the one that has been synchronized for three weeks. Why is the "best" node the one that gives the worst fee?

Just because the fee is lower does not mean it is better.

The fee estimator tries to estimate the fee the balances between cost and time to be included in a block. It does this by looking at the fee rates of transactions that it receives in its mempool and seeing how long it takes for transactions at a given fee rate to be included into a block. It becomes more accurate as it sees more transactions and more blocks because it has had more data to analyze.

So your two nodes are giving wildly different numbers because of their uptime. Node 1 has been online for much longer. It has seen more unconfirmed transactions become confirmed thus its estimator has had more data to observe.

However Node 2 has not been online as much so it doesn't have as much data. It hasn't seen as many blocks and as many transactions become confirmed. Since it has a lack of data it resorts to the fallback values. These values are the minimum relay fee rates which are not likely to actually be the true fee rate. The minimum relay fee rate is not the minimum to be included in a block, it is the minimum for a node to even relay your transaction to another node.

what can be done to make them more accurate?

Just wait. Leave the nodes online. The estimators require data and the only way to do that is to wait. They become more accurate over time.

Improve this answer
2
  • I was wondering if I copied .bitcoin/fee_estimates.dat from the node with higher uptime to the node with lower uptime, it would make them equal? If not, is there any way of exporting the feerate estimate data from one node to another? And how long is enough for the fees to become accurate? I assume there is a cap after some days of running, no?
    – Pedro
    Commented Feb 28, 2019 at 9:58
  • It seems that the trick I suggested really works, as morcos said here: bitcoin.stackexchange.com/questions/59854/… I was wondering what happens if a node hsa been running for a very long time and then it's stopped and restarted one month later. Are the estimates from one month ago decayed so much they are negligible or they still bear a heavy wait because it was "just before it restarted"? Also, is there a way to deserialize the information in fee_estimates.dat? I'd like to take a look at the information inside.
    – Pedro
    Commented Feb 28, 2019 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.