<p><strong>Running user nodes with a bigger than default mempool does not help the network, and might actually be detrimental in some scenarios</strong>.</p>
<p>Nodes only relay a transaction once to each of their peers when they first learn about the transaction.¹ After this initial relay, nodes <em>never</em> offer the same transaction again while it remains in their mempool.</p>
<p>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).</p>
<p>It is the responsibility of <em>sender (or receiver) wallets</em> 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 <em>will not relay</em> the transaction to their peers again (since it is not new).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<hr />
<p><sup>¹ There is a &quot;rebroadcast&quot; 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.</sup><br />
<sup>² Until we get Erlay.</sup><br />
<sup>³ Unless they run with <code>mempoolfullrbf=1</code> and allow replacements even when the original transaction signaled finality.</sup></p>

CC BY-SA 4.0
2023-05-04T17:43:35.017Z
2023-05-04T18:13:05.190Z
2023-05-04T18:13:05.190Z
Murch
<blockquote>
<p>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?</p>
</blockquote>
<p>No, and you may actually hurt the network in high fee scenarios.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-05-04T16:17:48.343Z
Good points. What if the node with a bigger than default mempool is also running with the parameter mempoolfullrbf=1? This is the case of my node with mempool size of 2 GB. In such a case it will not ignore rebroadcasted transactions - it will relay such transactions to its peers.
deyw
CC BY-SA 4.0
2023-05-04T16:24:23.610Z
"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" - is this really true? I believed that all nodes retransmit transactions periodically. This knowledge might prompt me to use the default mempool size for my node.
deyw
CC BY-SA 4.0
2023-05-04T16:48:20.230Z
@deyw Using mempoolfullrbf=1 does not affect rebroadcasts, it only affects what gets accepted into the mempool. With that option, it would accept and relay non-signaling replacements, but it would not rebroadcast anything. As for rebroadcasting, yes it is true that there is no periodic rebroadcasting that is done by nodes. This is currently a behavior that only wallets do.
Ava Chow
CC BY-SA 4.0
2023-05-04T17:11:19.557Z
Alright, I appreciate the explanation. Thanks Andrew.
deyw
CC BY-SA 4.0
2023-05-04T17:48:24.010Z
I feel like Andrew’s comment is ambiguous. To clarify: if a node gets a replacement transaction they will of course rebroadcast that replacement transaction, but `mempoolfullrbf` does not change the general behavior that every new transaction is only relayed once.
Murch
CC BY-SA 4.0
2023-05-04T20:08:23.983Z
Are there any planned or proposed changes in Bitcoin Core so that increasing one's mempool size wouldn't hurt the network?
Vojtěch Strnad
CC BY-SA 4.0
2023-05-04T14:48:24.773Z
2023-05-04T16:46:32.993Z
2023-05-04T16:46:32.993Z
Ava Chow
<p>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?</p>

<bitcoin-core><unconfirmed-transactions><network><mempool><relay>
How does it contribute to the Bitcoin network when I run a node with a bigger than default mempool?
Murch
# How does it contribute to the Bitcoin network when I run a node with a bigger than default mempool?

(Asked by: username_0 on 2023-05-04)

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?

**Tags:** bitcoin-core, unconfirmed-transactions, network, mempool, relay


---

## 2 answers

### Answer by username_1 on 2023-05-04. Score: 4 | Accepted answer

> 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.

> **Comments:**
> **username_2**: Good points. What if the node with a bigger than default mempool is also running with the parameter mempoolfullrbf=1? This is the case of my node with mempool size of 2 GB. In such a case it will not ignore rebroadcasted transactions - it will relay such transactions to its peers.  
> **username_2**: "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" - is this really true? I believed that all nodes retransmit transactions periodically. This knowledge might prompt me to use the default mempool size for my node.  
> **username_1**: @username_2 Using mempoolfullrbf=1 does not affect rebroadcasts, it only affects what gets accepted into the mempool. With that option, it would accept and relay non-signaling replacements, but it would not rebroadcast anything. As for rebroadcasting, yes it is true that there is no periodic rebroadcasting that is done by nodes. This is currently a behavior that only wallets do.  
> **username_2**: Alright, I appreciate the explanation. Thanks Andrew.  
> **username_0**: I feel like Andrew’s comment is ambiguous. To clarify: if a node gets a replacement transaction they will of course rebroadcast that replacement transaction, but `mempoolfullrbf` does not change the general behavior that every new transaction is only relayed once.  
> **username_3**: Are there any planned or proposed changes in Bitcoin Core so that increasing one's mempool size wouldn't hurt the network?  

---

### Answer by username_0 on 2023-05-04. Score: 1

**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.


---

