<p>There is no size limit to the mempool from what I can find. It might be possible to flood it but rather difficult and expensive / slow. I see two approaches:</p>

<p><strong>A) minimum relay fee</strong></p>

<ul>
<li>connect to 1000 nodes</li>
<li>send plenty of txs that meet the minimum relay requirements
<ul>
<li>how many?: 32 000 000, 32 000 on each node</li>
<li>nLocktime in the far future so they don't get into blocks</li>
<li>tx fee: minimum relay fee: 0.0001</li>
<li>amount: very low</li>
<li>size per tx: 250bytes</li>
</ul></li>
<li>mempools are filled with 8gb of dust</li>
</ul>

<p>It would take a while to generate that many addresses and tx and get them broadcasted. Also it would cost at least 3200BTC.</p>

<p><strong>B) 0 fee txs with minimum output of 0.01 so they still get relayed</strong></p>

<p>Mempool is gated by a rate limiter for free tx:</p>

<pre><code>// Continuously rate-limit free transactions
// This mitigates 'penny-flooding' -- sending thousands of free transactions just to
// be annoying or make others' transactions take longer to confirm.

// Use an exponentially decaying ~10-minute window:
// -limitfreerelay unit is thousand-bytes-per-minute

// At default rate it would take over a month to fill 1GB
</code></pre>

<p>So this will be at least very slow. Also you need to have 320 000 BTC for 8GB. :)</p>

<p>There might be ways to artificially make txs larger. Alternate clients might do things differently.</p>

CC BY-SA 4.0
2019-12-18T19:43:29.160Z
I'm not sure whether this got changed after this answer was written, but transactions with a `nLockTime` will not be relayed until the blockheight one before they can be included is reached or until the timestamp in the `nLockTime` has been reached. Therefore, a mempool flooding attack with locktimed transactions is not possible.
Murch
CC BY-SA 3.0
2013-03-30T09:57:02.763Z
2013-03-30T09:57:02.763Z
kermit
<p>nLocktime transactions that are not valid yet are not relayed and possibly even dropped. It's the responsibility of the sender and/or receiver to store the transactions until they are valid and then broadcast them.</p>

CC BY-SA 3.0
2014-10-04T02:52:09.693Z
2014-10-04T02:52:09.693Z
Jannes
<p>Transactions with a <code>nLockTime</code> set to a date or blockheight in the future will not be considered valid by Bitcoin Core until the timestamp has passed, or the block height one before they become valid has been reached. Only at this point, full nodes will keep them in their mempools and forward them.</p>

<p>Therefore, a mempool flooding attack with locktimed transactions is not possible.</p>

CC BY-SA 4.0
2019-12-18T19:45:35.300Z
2019-12-18T19:45:35.300Z
Murch
<p>What would happen, if I would create a large number of large transactions with a very high <code>nLockTime</code>?</p>

<p>Would something stop me from filling not only the miners', but also regular nodes' <a href="https://en.bitcoin.it/wiki/Protocol_specification#mempool" rel="nofollow">mempool</a>s?</p>

<p>Would miners drop transactions with unreasonably high <code>nLockTime</code> and low transaction fee?</p>

<p>What would BitcoinCore do?</p>

CC BY-SA 3.0
2014-10-03T10:52:52.687Z
The following was removed from the question, but would probably help to start an answer: theymos: "lockTime prevents a transaction from getting into blocks. Once it's in a block, it can be spent."
https://bitcointalk.org/index.php?topic=131443.msg1432948#msg1432948
Murch
<security><locktime>
Can nLockTime TX be used to flood Mempools?
kermit
# Can nLockTime TX be used to flood Mempools?

(Asked by: username_0 on 2013-03-15)

What would happen, if I would create a large number of large transactions with a very high `nLockTime`?

Would something stop me from filling not only the miners', but also regular nodes' [mempool](https://en.bitcoin.it/wiki/Protocol_specification#mempool)s?

Would miners drop transactions with unreasonably high `nLockTime` and low transaction fee?

What would BitcoinCore do?

**Tags:** security, locktime

> **Comments:**
> **username_1**: The following was removed from the question, but would probably help to start an answer: theymos: "lockTime prevents a transaction from getting into blocks. Once it's in a block, it can be spent." https://bitcointalk.org/index.php?topic=131443.msg1432948#msg1432948  

---

## 3 answers

### Answer by username_0 on 2013-03-30. Score: 2

There is no size limit to the mempool from what I can find. It might be possible to flood it but rather difficult and expensive / slow. I see two approaches:

**A) minimum relay fee**

* connect to 1000 nodes
* send plenty of txs that meet the minimum relay requirements
  + how many?: 32 000 000, 32 000 on each node
  + nLocktime in the far future so they don't get into blocks
  + tx fee: minimum relay fee: 0.0001
  + amount: very low
  + size per tx: 250bytes
* mempools are filled with 8gb of dust

It would take a while to generate that many addresses and tx and get them broadcasted. Also it would cost at least 3200BTC.

**B) 0 fee txs with minimum output of 0.01 so they still get relayed**

Mempool is gated by a rate limiter for free tx:

```
// Continuously rate-limit free transactions
// This mitigates 'penny-flooding' -- sending thousands of free transactions just to
// be annoying or make others' transactions take longer to confirm.

// Use an exponentially decaying ~10-minute window:
// -limitfreerelay unit is thousand-bytes-per-minute

// At default rate it would take over a month to fill 1GB

```

So this will be at least very slow. Also you need to have 320 000 BTC for 8GB. :)

There might be ways to artificially make txs larger. Alternate clients might do things differently.

> **Comments:**
> **username_1**: I'm not sure whether this got changed after this answer was written, but transactions with a `nLockTime` will not be relayed until the blockheight one before they can be included is reached or until the timestamp in the `nLockTime` has been reached. Therefore, a mempool flooding attack with locktimed transactions is not possible.  

---

### Answer by username_2 on 2014-10-04. Score: 1

nLocktime transactions that are not valid yet are not relayed and possibly even dropped. It's the responsibility of the sender and/or receiver to store the transactions until they are valid and then broadcast them.


---

### Answer by username_1 on 2019-12-18. Score: 0

Transactions with a `nLockTime` set to a date or blockheight in the future will not be considered valid by Bitcoin Core until the timestamp has passed, or the block height one before they become valid has been reached. Only at this point, full nodes will keep them in their mempools and forward them.

Therefore, a mempool flooding attack with locktimed transactions is not possible.


---

