Mempool data issues?

Embassy mempool data and charts don’t match mempool.space. I’ve always had an issue with the fee charts not retrieving data beyond a week or month (can’t remember). I can deal with that by looking at mempool space. However, I noticed a huge drop in fees last night while I had both tabs open (self hosted and .space). The EOS mempool showed the huge drop but .space did not. The recomended/priority fee bar/graph where suggested fees are shown are also way different. For instance, right now EOS mempool gives me (no priority to high priority) 2, 13, 16 and 22 sats/vb while .space gives me, 8, 13, 16 and 21. They’ve been much further apart as I refreshed at different times to check it.

I’ve restarted Core, Mempool, Electrs, and Proxy and refreshed the web UIs but the data remains different. Any clues?

One thing that can make the data (and fees) different is the size of your mempool. I know mempool.space uses a >1GB mempool to try and accurately reflect what most miners are incentivized to keep around. However, the default mempool max size in bitcoin core is 300MB. You can see what yours is set to in StartOS via:

Services > Bitcoin Core > Config > Advanced > Mempool > Max Mempool Size

Higher fee transactions are more sticky to your mempool because they jump in front of lesser-fee transactions, so as long as your mempool had hundreds of MB, upon first glance it may not seem like it should change your feerate estimates since many of the soon-to-be-most-recent blocks should more or less match mempool.space’s. However, take this scenario for instance:

You have your max mempool size set to 300MB
Miners and mempool.space use let’s say a 1GB max mempool size
150MB of your full 300MB mempool get mined, and in that time, another 150MB of new transactions are added to your mempool
If the 150MB of new transactions that were recently broadcast into your mempool had feerates lower than many of the ~700MB of transactions that were in miners’ and mempool.space’s mempools but not in yours, there are now many transactions that will be mined before the newest 150MB of TX that fill your 300MB mempool, so your node will not use those older transactions in its feerate calculations because it isn’t aware of them.

Once a transaction is initially broadcast around the network, it isn’t later periodically re-broadcast. Nodes only broadcast transactions when they first learn about them. So this could be what’s happening and throwing your feerate estimates off. If you have plenty of resources to spare (like RAM on your server), try increasing your Max Mempool Size.

3 Likes

Plenty of memory on the Pro. Raised core’s mempool to just over a gig. Restarted all BTC services and core. Same issue. It’s not a big deal. The only privacy I want from local mempool is TX tracking. I can do that just fine the way it is. I’ll just use mempool.space for fee estimates and history.

Thanks for the tip! Perhaps as the new settings get some new data things might align more? I also raised the persistence of the mempool data in core to one month (720 hours) from 14 days just to see if the added history might smooth out the differences. I had just been advising some friends of fee changes so they could save sats on TXs when I realized I might be giving them bad data.

Ah Ha! The length of the mempool persistence in core does make a difference to the charts I see in fees. With a 14 day persistence my fee chart did not change in the 1month, 3 month… views. When I changed it to 720hrs it now shows the 1month chart but did not add any data to the 3, 6month… etc charts.

Just for kicks, I raised mempool to 3gig and raised persistence to 1 year. Probably won’t leave it that way. Restarted all services again. No change beyond the one month fee chart or feerate calculations. I’ll give it some time to see if added data fills in some history and keep an eye on memory usage as well before I lower them back down.

Thanks again.

It may take a while for the fee estimates to catch up – because at the very least you’ll need to come close to filling up your 1GB with new transactions, and then all the transactions you won’t know about that miners are still holding onto will need to be mined. Once your mempools are the same or very similar, then and only then will your feerates estimates also match. Assuming my hypothesis is correct, the longer you wait after the mempool size change the more your estimates should converge with mempool.space’s.

1 Like

That’s what I was thinking. I’ll check back here with the results over time… if I don’t forget.

Well it’s been a while. Raising the mempool size to 3gig and persistence to a year didn’t change anything after almost two months. Fee estimates are still quite different as is the fee history charts. Guess I’ll use mempool.space for fee estimates and the Embassy mempool for TX queries. Not a big deal.

How much is “quite different?” My mempool reports a slightly different fee from the mempool.space website, but is within a couple sats/vB - plenty close enough to do fee estimation. Since these are individual mempools making individual estimates, they are unlikely to be exactly the same. I use 1GB and 1 month.

Its not much. The low estimate is almost always 2sats. The next three are close to .space. I can live with it, no problem. Just thought I’d repot back because I said I would.

Low Priority or No Priority? For me, No Priority basically always says 2sats lately. Perhaps there is something we can tweak here; I’ll look into it. Regardless, the Low/Medium/High are what you should be using for fee estimation.

No proority. The rest were like yours, One or two sat difference. There was a bigger difference before I raised the mempool settings. Im at 600meg and 3 months now.

I was mostly using it to help calculate whirlpool TXs. They have a lot more data and it helps me reduce bad bank… Penny pinching.

One Man’s penny-pinching is another Man’s best practice

I’m waiting to hear back from Mempool team if there’s anything we can tweak for better accuracy