I'm asking this question because sites seem to yield widely different estimates.

For instance, if I want a transaction to be accepted within 6 blocks, this is what I currently have to pay according to various calculators:

Why are the numbers so different? Who's right?

For the record: at first, I was convinced that bitcoinfees.net had to be wrong, but then, someone sent me a transaction (4a129199006935cad810f99a41c14b2e2cdc4f8043732fde8f6db3f7aa899dfc) with a mining fee of 5 sat/vB... and it received its first confirmation within 20 minutes. It makes me even more confused because I see many transactions currently paying a much higher mining fee.


TL;DR: you don't, you enable RBF and adapt the transaction fee to the block space market (or use a wallet that does).

Best effort(s)

First of all, in order to be reliable the estimation must not be game-able by miners (or at least, most of the estimations must not be). Therefore it must not be mempool-based (such as the electrs additional implementation, or by looking at Johoe's before making a transaction).
In this sense, the Bitcoin Core fee estimation (block chain based) is the most reliable.

Secondly, reliability is expensive. It can be measured by the statistical probability to get confirmed in less than N blocks. And by this metric, the most reliable method is again Bitcoin Core's.

Finally, i think you are interested in the most optimal estimate: that is both reliable (you are going to be confirmed before your target, and for the cheapest possible fee).
But such an estimate does not exist: the block space is a free market and no matter the statistical reliability of your estimate, if someone wants to fill the blocks up to your target with megabytes of high-fee-paying transactions, they just can.

A guess isn't reliable

Since you cannot reliably estimate transaction fees, you need to adapt your price to the market. However you will only witness the market actions after broadcasting your transaction. This is the reason behind Replace-by-fee (you need a way to bump your fees post-broadcast).

But RBF is opt-in, you need to enable it before performing a transaction. In case you already broadcasted your transaction, you can fall back to CPFP (spend the unconfirmed output with a second, high fee paying, transaction that pays for both --example with Electrum).

Conclusion -- what should i use?

It depends on your usecase.
If you are an occasional onchain user, you can afford the game-able and less reliable mempool estimations (see for example https://bitcoinqueue.com/#0,24h or the friendlier https://mempool.observer/).
If you are building an application, prefer Bitcoin Core's block chain estimations as:

  • For users reliability often outweighs cost (stuck transactions really aren't fun).
  • With a larger sample of transactions, statistics are on your side.
  • If all applications start relying on mempool estimations and fees continue to rise it becomes attracting for miners to collude :)

In both cases, when possible start with a lower estimation, enable RBF, and bump the fees as you are approaching your desired target without being confirmed.


My recommendation is to look at mempool.space before sending a transaction.

There you can either choose to trust their estimates which are posted directly on the site, or you can figure out yourself based on the actual fees also shown on the same dashboard having been paid in the previous few blocks, combined with information on the nr of transactions in their mempool etc, to make your own informed judgement.

Even better, you can run mempool.space on your own hardware showing you your own mempool from your full node, if you install e.g. the Raspiblitz on a raspberry pi. :)



I like to use https://jochen-hoenicke.de/queue/#0,2h

Presuming there is about 2,000 tx in a block I would pay 0.00070 BTC/KB to get into the next few blocks (probably the next)

enter image description here

This image shows there are 1712 tx paying more than 0.00060 but less than 736 paying 0.00070

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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