How does it contribute to the Bitcoin network when I run a node with a bigger than default mempool?

Question

Lately, when the blockspace demand outstrips the default mempool size and the dynamic minimum feerate of nodes rises above the minimum transaction feerate, I often see the suggestion to simply increase the size of my node’s mempool. If I increase my mempool to a much larger size so I can keep all the transactions other nodes are dropping, does that benefit the Bitcoin network?

Answer 1

If I increase my mempool to a much larger size so I can keep all the transactions other nodes are dropping, does that benefit the Bitcoin network?

No, and you may actually hurt the network in high fee scenarios.

Most nodes, including nodes operated by miners, do not use mempool policies that are different from the defaults. Given that the default mempool size is much larger than a single block, if default mempools were to become full, having a larger mempool does not help as the transactions that a larger mempool would keep around are those that would not be mined anyways.

If you are a miner, it may be beneficial if default mempools were full but subsequently emptied. In this scenario, the low fee transactions that were evicted by default mempools may still be retained by larger mempools and therefore mined. But this only really helps miners, not the network as a whole.

However, I don't think having a larger mempool meaningfully helps in the miner scenario as wallets will rebroadcast their transactions if they are important. Most wallets have a periodic rebroadcast, so if the mempool is emptied, those low fee transactions will be rebroadcast and miners will learn about them again in and be able to mine them.

In fact, since many wallets do periodically rebroadcast transactions, larger mempools will actually hurt this rebroadcasting. Nodes only announce the transactions that they did not already know about. If a node with a larger mempool receives a rebroadcast of a transaction it already knows about, it will just ignore it and not even relay that transaction to its peers, which may not know about it. This would hurt the propagation of rebroadcasts.

Additionally, nodes do not rebroadcast on their own, so a node with a larger mempool doesn't have any mechanism to make that transaction more available on the network. It just becomes a black hole for the rebroadcasting of such transactions.

Lastly, having a larger mempool hurts the propagation of non-signaling replacement transactions. Users may create replacement transactions for their original low fee transactions even if they did not opt in to RBF. They are able to successfully do this when most nodes evict the transaction, which they can generally learn by observing a default mempool's evictions. A node with a larger mempool would reject such replacements as they would conflict with a non-signaling transaction, so this can hurt the propagation of higher fee replacement transactions. For miners, this can also hurt as they would not be aware of the better replacement transaction.

Answer 2

Running user nodes with a bigger than default mempool does not help the network, and might actually be detrimental in some scenarios.

Nodes only relay a transaction once to each of their peers when they first learn about the transaction.¹ After this initial relay, nodes never offer the same transaction again while it remains in their mempool.

There is also no mechanism for nodes to synchronize their mempools with peers.² If a node was not online while a transaction was relayed on the network, the node will only hear about the transaction when it is included in a block (or due to a rebroadcast by the sender).

It is the responsibility of sender (or receiver) wallets to ensure that the transactions they want to see confirmed are present in the network’s mempools. Most wallets ensure this by rebroadcasting unconfirmed transactions periodically (which is a privacy leak that ¹ would address). If a transaction was evicted previously from mempools, it will relay just like an initial broadcast if it’s now eligible for most mempools again. Since some portion of the node population is only online intermittently, a rebroadcast may also relay to some extent among nodes that have not seen it before. During a rebroadcast, all nodes that still have a transaction will not relay the transaction to their peers again (since it is not new).

This means that if a significant portion of nodes use a larger mempool or longer timeout period they may actually hinder the rebroadcast of a transaction that previously got evicted or the submission of a conflicting replacement of an abandoned transaction.³ Either way, the network works best if all nodes roughly keep the same transactions in their mempools.—Block propagation works well, because nodes already know about the transactions that get included in blocks, and rebroadcasts work well, because when they’re necessary, they’ll also relay reliably.

The two exceptions may be nodes used to collect statistics on unconfirmed transactions and miners. A miner that keeps a bigger mempool might have some transactions left to include in blocks even after the default mempool clears. However, if such a miner still keeps an original transaction that everyone else dropped, they might reject a conflicting replacement transaction with a higher fee if the original did not signal replaceability³, while most nodes on the network would now hold the replacement.

Finally, a smaller mempool also has downsides, it may make your node less capable of predicting feerates and slow down your block processing if blocks start including transactions that you previously evicted compared to nodes that still hold them.

---

^{¹ There is a "rebroadcast" project that aimed to change the behavior of Bitcoin Core. The idea is that a node will rebroadcast those transactions from its mempool that it would have expected to have been in the prior block. This project has not been merged yet.
² Until we get Erlay.
³ Unless they run with mempoolfullrbf=1 and allow replacements even when the original transaction signaled finality.}