Reliability of sites such as mempool.space for estimating fees.

[tranthidung]

It is very bad designed, bad organized in fee rate bands' colors.

What? First time hearing a bad experience with mempool.space. They're like the most favorite block explorer. Tells you exactly what you need to know, and the styling rocks. What hot and cold colors? Why should high fees be red flag if there aren't overpaying?

Nope.

I did neither mean about accuracy of mempool.space fee recommendations nor the color in your screenshot. I meant that band colors in their chart and about red flag, overpaying, it is exactly what I meant.

Like on Jochen-hoenicke.de, when fee rate band color hits hot bands like red, it means overpaying. For lower fee rates, even you are overpaying, it is still fine because not too much expensive.

Compares it to mempool.space, I hope you see difference in their color design. Let me emphasize, I only dislike colors used in their chart.

[o_e_l_e_o]

Like on Jochen-hoenicke.de, when fee rate band color hits hot bands like red, it means overpaying.

That's not what the colors on Jochen's site mean. The fee bands are simply different colors. There is no color that means "overpaying". Go back to May this year or go back to the end of 2017 and there were plenty of times when you had to pay fees in the red bands to have a reasonable chance of being confirmed within the next few hours. This was not an overpayment, but rather completely appropriate.

[NotATether]

I did neither mean about accuracy of mempool.space fee recommendations nor the color in your screenshot. I meant that band colors in their chart and about red flag, overpaying, it is exactly what I meant.

Like on Jochen-hoenicke.de, when fee rate band color hits hot bands like red, it means overpaying. For lower fee rates, even you are overpaying, it is still fine because not too much expensive.

Compares it to mempool.space, I hope you see difference in their color design. Let me emphasize, I only dislike colors used in their chart.

You can reverse the colors used on the chart because it's implemented as a gradient, and then run your own frontend - since this stuff is defined inside Angular source which is then compiled down into not-so-easy-to-edit JS.

First go to this file: https://github.com/mempool/mempool/blob/master/frontend/src/app/components/svg-images/svg-images.component.html

Clone the repository, and change all the instances of this:

Code:

          <stop stop-color="#AE61FF"/>
          <stop offset="1" stop-color="#13EFD8"/>

to this:

Code:

          <stop stop-color="#13EFD8"/>
          <stop offset="1" stop-color="#AE61FF"/>

Then follow the instructions to self-host Mempool.space on your own hardware.

[LoyceV]

I never really looked at it before until now:

It looks like their estimate in confirmation time is based on the assumption that no new transactions are being made. So, if you pay 12 sat/vbyte now, your transaction will be in the fifth block. That sounds acceptable to me, except for the fact that there's about 1 block worth of new transactions every 10 minutes, so it can take days to clear just those 5 blocks.

[NotATether]

It looks like their estimate in confirmation time is based on the assumption that no new transactions are being made. So, if you pay 12 sat/vbyte now, your transaction will be in the fifth block. That sounds acceptable to me, except for the fact that there's about 1 block worth of new transactions every 10 minutes, so it can take days to clear just those 5 blocks.

To be fair, there isn't a way to figure out how many new transactions will be produced in advance.

Maybe a machine learning model could be made, that looks as previous mempool activity over the past 2 or 3 years and then tries to estimate how many new blocks will be created at any given time, and then estimate the median fee for all of these transactions, and then "push" the stated transaction fee right now closer towards this median. But that would be resource intensive.

[LoyceV]

To be fair, there isn't a way to figure out how many new transactions will be produced in advance.

Maybe a machine learning model could be made, that looks as previous mempool activity over the past 2 or 3 years and then tries to estimate how many new blocks will be created at any given time

I would extrapolate the transactions made in the past few hours, and use that as an estimate of transactions in the coming hours. It's not always accurate and there can be exceptions, but most of the time it's pretty accurate.
That's why I like Johoe's site: it quickly shows fees are currently slowly going up, which means if you pay the minimum and it doesn't get confirmed quickly, it's likely to take a lot longer. If it would have been the opposite and fees are slowly dropping, paying the minimum is likely to get your transaction confirmed quickly.
I can't get this information from mempool.space's estimate.

[hosseinimr93]

It looks like their estimate in confirmation time is based on the assumption that no new transactions are being made. So, if you pay 12 sat/vbyte now, your transaction will be in the fifth block.

According to the image you posted, mempool.space is saying that if no new transaction is made, the next block will include transactions using the fee rate of at least 14 sat/vbyte and the fifth block will include tranactions paying 11-12 sat/vbyte.
Mempool.space isn't saying that if you use the fee rate of 12 sat/vbyte, your transaction will be included in the fifth block.

If you want to use mempool.space for fee estimation, you should use the fee rates displayed under "High Priority", "Medium Priortiy" and "Low Priortiy"

Mempool.space suggests using the high priority fee rate for placing your transaction in the first mempool block, the medium priority fee rate for placing your transaction between first and second mempool blocks and the low priority fee rate for placing your transaction between second and third mempool blocks.


See the image I just took from mempool.space.



According to the image, Mempool.space is saying that if no new transaction is made, the next block will include transactions paying the fee rate of at least 15 sat/vbyte and the second block will include transactions paying 14-15 sat/vbyte.
Mempool.space is suggesting the fee rate of 18 sat/vbyte for placing your transaction in the next block and the fee rate of 17 sat/vbyte for placing your transaction in the next two blocks.

[o_e_l_e_o]

More specifically, you can read how the suggestions are calculated here: https://github.com/mempool/mempool/blob/827b0f6ad1c419e79d1a5cfa55b74b9c993a4748/frontend/src/app/docs/api-docs/api-docs.component.html#L199

Snipped and reformatted for easier reading:

High Priority. This figure is the median feerate of transactions in the first mempool block. Consider using this feerate if you want confirmation as soon as possible.

Medium Priority. This figure is the average of the median feerate of the first mempool block and the median feerate of the second mempool block.

Low Priority. This figure is the average of the Medium Priority feerate and the median feerate of the third mempool block. Consider using this feerate if you want confirmation soon but don't need it particularly quickly.

No Priority. This figure is either 2x the minimum feerate, or the Low Priority feerate (whichever is lower). Consider using this feerate if you are in no rush and don't mind if confirmation takes a while.

In all cases, the suggested feerate is adjusted lower if any of the mempool blocks involved in the calculation are not full (example: if there is only 1 mempool block that's less than half-full, Mempool will suggest a feerate of 1 sat/vB—not the median feerate of transactions in the block).

As I said earlier in the thread, I think those estimates are bit on the high side. At the moment, the "No Priority" fee of 16 sats/vbyte still puts the transaction less than 1.5 MvB from the tip, which is not what I would call "No Priority".

[tranthidung]

Like on Jochen-hoenicke.de, when fee rate band color hits hot bands like red, it means overpaying.

That's not what the colors on Jochen's site mean. The fee bands are simply different colors. There is no color that means "overpaying". Go back to May this year or go back to the end of 2017 and there were plenty of times when you had to pay fees in the red bands to have a reasonable chance of being confirmed within the next few hours. This was not an overpayment, but rather completely appropriate.

I agree with you but let me explain why I prefer Jochen-hoenicke.de site again.

Even the red bands in Jochen-hoenicke.de don't always mean overpaying but also can means expensive, sometimes they are fee rates you have to pay to get a confirmation quickly (next few blocks), in my view, it is still a red flag (warning) for people. If you are not in emergency to move coins, it's good to sit back, think more about red-banded fee rates and you can wait a few days, weeks to move your coins. With this view, that site and its color design are very helpful.

My guess only but likely the person behind that site, actually has clear idea about what colors to use and for what purposes. It's different than mempool.space and how they use colors.

You can reverse the colors used on the chart because it's implemented as a gradient, and then run your own frontend - since this stuff is defined inside Angular source which is then compiled down into not-so-easy-to-edit JS.

First go to this file: https://github.com/mempool/mempool/blob/master/frontend/src/app/components/svg-images/svg-images.component.html

Clone the repository, and change all the instances of this:

Thank you, I don't have skills to do that but your post is damn helpful, I like it.