I am looking for a comparison or summary of different fee estimation algorithms. Does anyone know of one? I would like to see what the best starting point is in order to see where optimization can be done.

From a cursory search, there is documentation for Bitcoin Core's fee estimation, but there are many other providers including APIs like Earn/Blockstream/Bitgo. They all provide estimates which are different from Bitcoin Core's estimation. I am assuming that their mempool is similar but their algorithm is different.

For reference, so far I have found John Newbery's outline on Core's fee estimation, a gist by Alex Morcos with a High level description Bitcoin Core's fee estimation algorithm, and of course the Bitcoin Core code itself.

  • Hi mango, thank you for a great first question. I have packed your links into the flow of the text to make the question a bit more readable, and added more relevant tags. Please feel free to rollback or edit further any of my changes. I have changed the question's scope slightly to ask for one place to start, as asking for multiple gave the topic a bit of a "shopping list question" character. :) – Murch Nov 11 '20 at 18:58
  • Hi mango, I am very interested in this topic, please feel free to get in touch. – Pedro Nov 12 '20 at 0:44

TLDR: You can find some OLD 2019 DATA comparing their accuracy for one-hour estimations here: https://bitpost.co/evaluations

I asked myself this question about two years ago and wasn't able to find an answer. I then set out to build an app that measured how accurate fee estimations from various sources were. Below are the design choices and some OUTDATED results.

The first challenge I found was that fee estimations come under many different formats, some recommend in time horizon, others in a block horizon. I made the simplification of converting all time horizon estimations to block horizon estimations. This is questionable because some estimators might be more accurate because they take into account that certain epochs are faster than others (hash rate changes). However, this resolves ambiguous situations where a block comes around the estimation horizon: suppose you make a fee estimation for 20min from now, and the second block arrives at 20min 1 seconds, do you include that block or not?

Another important consideration is "What does it mean to estimate a fee of, say, 8 sat/B for a one-hour horizon?". Does it mean that in 80% of the cases that will be enough? Or 50% of the cases? Bitcoin core estimator has for example two modes of estimation "ECONOMICAL" and "CONSERVATIVE". So, the first time in measuring the accuracy of a fee estimator should be to assign a statistical meaning to the fee estimation. I call this, finding the implicit probability of a fee estimator: the probability for which, the fee estimator achieves its highest accuracy.

Below I paste from https://bitpost.co/evaluations/help an outline of the procedure I used:

  • First, the application 'observes' a type of recommendation and assigns a probabilistic meaning to each recommendation type. For example, bitcoin core's 'economical' fee recommendations could mean 40% probability of being a transaction with the recommended feerate (sat/byte) be mined while bitcoin core's 'conservative' fee recommendations could mean 70% probability.

  • The application gathers a recommendation and hundreds of transactions that arrive at the bitcoin mempool during this period (new pending transactions).

  • According to the target of the recommendation (2,3,4,etc. blocks), it waits until that target is reached.

  • The application, by analyzing what transactions were mined and which ones weren't, derives a range of correct recommendations. If the recommendation given is out of this range, the error of the recommendation is given by subtracting from it the correct recommendation.

In https://bitpost.co/evaluations I show some of the results that I got in 2019. One evaluation means corresponds to one observation that is considered valid for one-minute. The measured fee estimators were:

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.