[Oct 2026]Mempool empty, Consolidate your small inputs @0.25 sat/vbyte

[Cricktor]

I strongly believe your local mempool.space instance doesn't see quite a bunch of transactions which are currently visible in mempools of my own node and the public mempool of https://mempool.space. Are you sure your node's mempool accepts transactions below 1sat/vB?

This is what my local instance of mempool.space app shows for my node:


This is what public mempool.space shows, maybe just a few minutes later than my screenshot above:


Past 30 day of mempool.jhoenicke.de:


Another mempool history from https://chainquery.com/reports/mempool:


My node and mempool transaction count history from Fulcrum Electrum server logs also have the "low waterlevel" from around end of August until around Sept. 16^th, 2016 ~11:xx UTC when mempool tx count hovered in the ballpark around 30k and rose within two hours to around 80k tx.

[logfiles]

I strongly believe your local mempool.space instance doesn't see quite a bunch of transactions which are currently visible in mempools of my own node and the public mempool of https://mempool.space. Are you sure your node's mempool accepts transactions below 1sat/vB?

You might be right. I am using https://mempool.bitmixlist.org because for some reason,  the main website (mempool.space) sometimes does not load on at all even when I use the VPN service. It goes on for even weeks and then works for one day and then it's off again 

So when I saw the nearly empty mempool, i thought we were back to those old times.

[Cricktor]

I am using https://mempool.bitmixlist.org ...

So when I saw the nearly empty mempool, i thought we were back to those old times.

Ah, OK, so it's not your local instance but IIRC NotATether's public https://mempool.bitmixlist.org. I wonder why his mempool is so "empty" when mine and official https://mempool.space's are pretty close together and have a few tenthousand tx more.

With the current state of mempool having enough transactions to fill roughly a backlog of around 40 blocks, the topic title saying "Mempool empty" isn't quite accurate if I'm in nitpicking mode. Depends on the perspective, I guess. With a floor value of 0.3sat/vB the candidate block regularly "dries out", see below screenshot when pink horizontal line is crossed under:


With 0.1sat/vB minimum relay feerate I don't expect the mempool to ever truely dry out significantly so that one could call it really "empty".

There will always be some inscription/Runestone/whatever shenanigans to vomit their crap into mempools. It stinks...

[NotATether]

I am using https://mempool.bitmixlist.org ...

So when I saw the nearly empty mempool, i thought we were back to those old times.

Ah, OK, so it's not your local instance but IIRC NotATether's public https://mempool.bitmixlist.org. I wonder why his mempool is so "empty" when mine and official https://mempool.space's are pretty close together and have a few tenthousand tx more.

There was some maintenance last night that took down the explorer and electrs for a few hours, but that isn't the reason mine shows a lower tx count.

Apparently, the missing transactions are almost entirely Runes and other extremely low-paying datacarriers that a default node does not see due to eviction policies, but mempool.space's config chooses to display for some reason.

Mempool.space uses a huge maxmempool value, whereas mine is running 31.1 with the default 2-week eviction.

So what you see on BitMixList's mempool is actually the "true" mempool volume over two weeks.

[Cricktor]

Mempool.space uses a huge maxmempool value, whereas mine is running 31.1 with the default 2-week eviction.

So what you see on BitMixList's mempool is actually the "true" mempool volume over two weeks.

My Core 31.1 node has explicitly the setting mempoolexpiry=336 which translates to eviction after 14 days, same as your node. So, I don't think transaction eviction plays a significant role in the difference of your and my mempool.

I have maxmempool=512 and persistmempool=1 in my bitcoin.conf, not sure if this could play a role. This way it repopulates my mempool pretty fast if my Linux box needs just a reboot because of some updates that mandate one. I prefer it that way.

Another of my Core nodes has a larger mempool, maxmempool=1024, but at current "waterlevel" this doesn't make a difference. Both have nearly the same tx count in their mempools and are also connected to each other.

Anyway, I don't know an obvious reason or setting that stands out to explain the difference. There are a few other settings where I can think of some influence, but I'm not sure if it's really important.

If it is for you, let me know and I can disclose most of my settings in my bitcoin.conf file.

[NotATether]

If it is for you, let me know and I can disclose most of my settings in my bitcoin.conf file.

That won't be necessary. I've decided to modify the parameters to better reflect mempool.space.


I found a nasty bug which can cause mempool/electrs to hang during shutdown, but the Github repo is locked to contributors only, so I have no way to report this or submit a PR.

[Cricktor]

That won't be necessary. I've decided to modify the parameters to better reflect mempool.space.

Curious, would you disclose what changes you applied to achieve this?

[NotATether]

Curious, would you disclose what changes you applied to achieve this?

Setting mempoolexpiry=87600 and keeping maxmempool=1000 as before, followed by fetching all the missing transactions from Mempool.space to my own server and manually adding them back into my Bitcoin Core node.

Also the reboot from a few days ago messed with the mempool, which had already been resolved.

[Cricktor]

Ten years mempool retention time seems quite excessive, not really judging here. So your node's mempool basically doesn't forget a transaction that isn't confirmed for whatever reasons and isn't evicted should your already larger mempool run full.

Hm, while I use a 512MB mempool on the node that feeds my Fulcrum electrum server and a 1024MB mempool on another node, I don't do anything special with them. The persistant mempool config for both nodes is mostly sufficient for me that both seem to recreate their mempool with a comparable to mempool.space number of transactions after few hours of being online (actually I don't monitor this closely). It seems pretty similar to me when I happen to look at mempool.space and both of my nodes roundabout at the same time.

Anyway, thanks for the insight.

[LoyceV]

Ten years mempool retention time seems quite excessive

Does that mean it's also broadcasting them to other nodes for 10 years, so even if miners dropped the transaction, they'll pick it up again?

[athanred]

Does that mean it's also broadcasting them to other nodes for 10 years, so even if miners dropped the transaction, they'll pick it up again?

Not really. If nobody is requesting a given transaction, then mempool.space does not broadcast it by default.

Which is why in testnets, where new miners were joining, mempool.space displayed, that everything is clogged, while miners heard not that much new transactions, and mined half-empty blocks.

And then, people paying 10 sat/vB or 100 sat/vB actually overpayed, while they could get things confirmed at 1 sat/vB without any problems, because miners simply had much less transactions, than mempool displayed.

Since then, I consider mempool.space transaction propagation to be kinda bugged. If you don't broadcast your transaction by yourself, then simply assume, that others may not do that for you, if they have no incentive. Some nodes can store your transaction, and know about it, but not broadcast it randomly, if you won't ask them specifically about this particular txid.

Edit: Also, I am not the first one, who noticed this bug. Similar topic about buggy mempool.space: https://bitcointalk.org/index.php?topic=5528236

[TheButterZone]

mempool.space's space LOL: https://matrix.to/#/#mempool:bitcoin.kyoto

[nc50lc]

Ten years mempool retention time seems quite excessive, not really judging here.

On the other hand, the original mempool.space has it set to basically forever: mempoolexpiry=999999 and maxmempool=4096
So their blockexplorer isn't a good representation of a standard node's mempool, but more of an archive of unconfirmed transactions.

Ref; Permalink based on live version's current commit: github.com/mempool/mempool/blob/5b8486a9e376ec8d1e3658c8256a4e2de95d2e85/production/bitcoin.conf#L22-L23