Interesting historical context here: _way_ back in the day Mike Hearn advocated to use rate limiting to make `nSequence` based transaction replacement “work”.

What that means is while replace-by-fee allows a transaction to be replaced by a higher fee, `nSequence` replacement just lets you replace a transaction an essentially unlimited number of times without paying anything extra.

Of course, that was insane, so we got replace-by-fee instead.... but all these years later we're still adding rate limiting to cut down on any issues left over in edge cases.

Belt and suspenders!

> Every time I hear about something that people are working on in Bitcoin, it opens a huge door where I discover all kinds of things I didn't know.

+1

I didn't realize how the fact that nodes create this flooding dynamic is actually such a risk: every node broadcasts a new transaction to all other nodes that don't know about it. So each new transaction quickly floods the network. You might think this was not a great attribute to have in a permissionless peer-to-peer pseudonymous network. 

So instagibs came up with some rate-limit rules for such a network:

> * should keep your CPU available for validating blocks and transactions, not use it all up for resorting the same set of txs for each peer
> * should cope cleanly with large backlogs of transactions
> * should smooth out large transaction bursts, focusing on relaying the txs in the top of the mempool (per cluster mempool rules, of course)
> * introduces a new bandwidth ratelimit that should prevent excessive numbers of large transactions that never confirm from blowing out your VPS’s monthly limit, even if you have a couple of hundred peers to relay those txs to

Every time I hear about something that people are working on in Bitcoin, it opens a huge door where I discover all kinds of things I didn't know.

Scoresby

 merged into Bitcoin Core for the 32.0 release in the coming months.

It’s (hopefully!) the conclusion to three years of (on and off) work, beginning (from my perspective) with an alert from the VPS hosting my mainnet debug-build node that it was using excessive CPU, along with log entries indicating it was taking 80 seconds to accept individual txs to the mempool:

bitcoin

> *by* [**ajtowns** ](https://delvingbitcoin.org/u/ajtowns)
>
> Very pleased to have [#34628](https://github.com/bitcoin/bitcoin/pull/34628) merged into Bitcoin Core for the 32.0 release in the coming months.
>
> It’s (hopefully!) the conclusion to three years of (on and off) work, beginning (from my perspective) with an alert from the VPS hosting my mainnet debug-build node that it was using excessive CPU, along with log entries indicating it was taking 80 seconds to accept individual txs to the mempool:
>
> ```
> 2023-05-03T12:08:22Z [lock] Enter: lock contention cs_main, net_processing.cpp:1450 started
> 2023-05-03T12:08:49Z \[lock] Enter: lock contention cs\_main, net\_processing.cpp:5116 started
> 2023-05-03T12:09:30Z \[mempool] Removed 2 txn, rolling minimum fee bumped to 0.00003008 BTC/kvB
> 2023-05-03T12:09:30Z \[mempool] AcceptToMemoryPool: peer=2550: accepted 45d87efceeb53745408114f6ad291c01349388483eaaf861a5c8f2e4cc198a99 (poolsz 65133 txn, 197357 kB) feerate=124.00
> 2023-05-03T12:09:30Z \[lock] Enter: lock contention cs\_main, net\_processing.cpp:1489 completed (85,862,565us)
> ```
>
> [https://bitcoincore.org/en/2024/10/08/disclose-large-inv-to-send/](https://bitcoincore.org/en/2024/10/08/disclose-large-inv-to-send/)
>
> [https://b10c.me/observations/15-inv-to-send-queue/](https://b10c.me/observations/15-inv-to-send-queue/)
>
> [**...read more at delvingbitcoin.org**](https://delvingbitcoin.org/t/transaction-rate-limiting/2744)