Discussion of Default Dynamic Size Limit (Default mempool of 320MB/serialized mempool of 100MB)

Protocol
#1

As it has come up, starting the discussion about forming consensus around updating the default mempool size limit.

For brief context, the serialized size limit currently is 100MB – this means that after this is filled, lower fee txs will be evicted from the mempool/rejected from being broadcast. 100MB is roughly 3 blocks worth.
This is a remnant of Core.

@bitcoincashautist @tom were discussing this earlier, so tagging them here as they would be more relevant to beginning this discussion.

In short, first determining if this is an issue – I would hope we don’t get to a period of many full blocks, and having higher fees at a certain mempool size can discentivize spam attacks, or make them more expensive at least (either in cost or in time). Though on the other hand, having txs booted at only 3 blocks worth of mempool would also cause issues as most wallets default to 1sat/byte and it won’t be good if users can’t figure out why they cannot broadcast. This leads me to believe that at a minimum, this limit should be raised.

#2

To be fair, this is not entirely appropriate here as this is a BCH-Node specific setting, and default (and feature).

But since I did some research I’m willing to repeat this here.

  • BCH-Node has inherited commit 8af5aceb50 which sets the max mempool size to be equal to 10 x the max block-accept size (the 32MB thingy).

  • As per BCA, the effective 320MB isn’t actually the raw transactions it fits, instead it accounts for all the vectors and stuff that are overhead in BCHN in the “CTransaction” class. This is set to 3.2.
    This effectively finishes the math to be 32 * 10 / 3.2 = 100, which is what mini satoshi wrote above.

  • this PR; https://github.com/bitcoin/bitcoin/pull/6722 from 2015 (not on flowee, not on BU unless backported) follows a simple algo (according to the text, I didn’t read code) that when that 100MB is full, it starts ejecting transactions by lowest fee and at the same time auto-increase the min-relay fee for some time.

My observation on Telegram was that 100MB (effective blocksize) is too little and any full node should absolutely be able to assign more to the mempool if it attempts to be useful to its operators.
Even a raspberry Pi model 4 (started shipping 2019) shipped with 4GB and later 8GB ram, normal operators will be able to have even more ram available in normal situations. Only exceptionally terse systems may need to adjust the mempool size, but the default can probably be significantly increased.

I think it is the responsibility of the BCHN team to make such properties follow reality, I hope they can include a good increase in the next release as I think the halving showed this value is too small.

#3

@_minisatoshi you know you can just open an issue here: Issues · Bitcoin Cash Node / Bitcoin Cash Node · GitLab

Anyway, it’s nice that this got some visibility and people learned about the dynamic min. fee

2 Likes
#5

Yep, that’s why I put it here – open it to more eyes

2 Likes