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' mempools?

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

What would BitcoinCore do?


3 Answers 3


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.

  • 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
    Commented Dec 18, 2019 at 19:43

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.