[feat]: Consider increasing `maxmempool` default

[kristapsk]

Prerequisites

• I have searched for existing issues that already suggest this feature.

Describe the Feature Request

See bitcoin/bitcoin#27079 for context.

Embassy devices have 8 GB or more RAM. It should be enough to increase 300 MB maxmempool default of Bitcoin Core.

Describe the Use Case

Recently total size of unconfirmed Bitcoin transactions has spiked above 300 MB maxmempool default, which makes nodes with default config to start dropping lower fee transactions. If hardware allows it, I see no downsides in increasing this default.

Describe Preferred Solution

No response

Describe Alternatives

No response

Anything else?

No response

[chrisguida]

I see no reason to diverge from Core's official defaults. If you would like a larger mempool you can always increase the setting manually.

[petertodd]

If hardware allows it, I see no downsides in increasing this default.

One downside is that because of your larger mempool, you would accept transactions for relay at a lower fee rate than other peers would accept. Thus you're wasting their bandwidth by relaying them transactions that they're not interested in. The feefilter feature is supposed to mitigate this. But it takes time to activate and doesn't kick quickly in for small changes in fees.

Secondly, nodes with non-standard default fees make it harder to re-propagate transactions once the min-fee reduces: because they already have the transaction, they won't rebroadcast it when one of their peers gives them the transaction again.

Finally, what's the point of having transactions in your mempool that won't be mined for days, if ever? Hardly any Start9Labs nodes are being used for mining. Meanwhile, the memory used could be better used by the OS filesystem cache to cache the UTXO set. Additionally, you could consider increasing the size of the in-memory UTXO cache instead.

[kristapsk]

memory used could be better used by the OS filesystem cache to cache the UTXO set. Additionally, you could consider increasing the size of the in-memory UTXO cache instead.

That's a good argument!