mempool: Increase mempool default size

[ghost]

Bitcoin Core 0.12 will have a strict maximum size on the mempool. The
default value is 300 MB and can be configured with the -maxmempool
parameter. Whenever a transaction would cause the mempool to exceed
its maximum size, the transaction that (along with in-mempool descendants) has
the lowest total feerate (as a package) will be evicted and the node's effective
minimum relay feerate will be increased to match this feerate plus the initial
minimum relay feerate. The initial minimum relay feerate is set to
1000 satoshis per kB.

Its been more than 5 years since this was set. We have better configs on desktop and server machines. Bitcoin can have 900 MB of mempool.

Why change default when users can change it?

Because DEFAULT matters

---

Hopefully mempool "wizards" dont have issues with it?

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	Xekyo, dergoegge
Concept ACK	taxmeifyoucan

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

[murchandamus]

Could you perhaps elaborate on the motivation? It’s not clear to me what problem this would solve.

[ghost]

Could you perhaps elaborate on the motivation? It’s not clear to me what problem this would solve.

We sometimes feel a few things are easier or better as they have been working for years, however this was the first time I interacted with a guy who already understood how mempool works for other blockchains that I dont want to mention here. It was difficult to educate him about about fee bumping and how this could be avoided if some transaction get dropped in a few minutes.

The limit I shared was 300 MB for most nodes, maybe some nodes use less or more but it wont get propagated if default is less.

This motivated me to increase the mempool size as I feel 300 MB is way less than machines we have today. I never imagined I will have a phone with more RAM than my laptop in 2016. It is possible today and we have better configs for mobile, desktop and server machines.

[murchandamus]

Concept NACK

I may be convinced otherwise, if evidence is provided that this does not increase the DOS attack surface, does not increase bandwidth use, and the increased memory use yields any sort of measurable benefit whatsoever.

[ghost]

this does not increase the DOS attack surface, does not increase bandwidth use, and the increased memory use yields

I am not sure if your NACK has any data to prove it increases DoS attack surface. It is mostly based on some topics that you think affects mempool.

Bandwidth: I dont live a first world country and still enjoy unlimited data
Memory: Already explained above that things have changed since 2016 (maybe not some people but hardware)

[dergoegge]

Concept NACK🪄

The rational that is provided here is unconvincing.

[ghost]

[taxmeifyoucan]

Concept ACK. We saw mempool being filled multiple times before and bigger size might help with spikes. But bumping it 3x seems like a bit step even considering average RAM. 400-500MB would be still fairly conservative but provide significant help with transaction spikes.

[kristapsk]

Maybe good start would be to discuss first changing defaults in Bitcoin full node distributions like RaspiBolt, RaspiBlitz, Umbrel, etc...?

[Sjors]

I believe there was no mempool limit until late 2015, a 300 MB limit was added in 794a8ce.

With the recent influx of relatively large blocks it still fit 70 blocks worth of transactions. Assuming 50% overhead in the way we store transactions in the mempool, I think the worst case is 40 blocks, or about 6 hours. This is significantly less than the default expiration of mempool transactions, which is two weeks. Before SegWit, our mempool would fit 1 day of worst case blocks.

So one could perhaps argue that it's annoying that you can't in practice send a transaction at a low fee rate, that is likely to confirm within one day. But even increasing the default mempool by 4x isn't going to be much help if you're trying to sit out a multi-day surge.

So I think it's more useful to continue working on having the wallet / node rebroadcast transactions in a privacy-preserving manner. For nodes that are always on that should be enough.

changing defaults in Bitcoin full node distributions like RaspiBolt, RaspiBlitz, Umbrel, etc

They could inspect the total memory* on the machine and then pick a larger mempool. To prevent fingerprinting though, I suggest limiting the options, e.g. either 300MB or 1GB. * = also useful for picking a good -dbcache value to speed up IBD.