What is protecting the mempool from being DDOSd?

Question

The mempool currently seems to contain almost 60K unconfirmed transactions, and the number seems to be growing. According to this question, it seems that unconfirmed transactions are eventually purged.

Other answers indicate that it is impractical to hamper the transactions of others to go through by trying to fill blocks with your own transactions. That question does however not mention problems that the nodes would face in having to deal with a too large number of transactions being passed around (without considering them being included in the block at all).

Would it be possible for a malicious user to send a lot of transactions (say from the same valid address) to the network, aiming to increase the size of the node mempools, and thus cause problems? Has something like this happened?

Or does the purging happen fast enough, and are the unspent transactions small enough, for a growing mempool not to be a problem for the network nodes? Are there any other common features implemented that protect against a bloating of the mempool?

Answer 1

First of all, there is no "The mempool". Every full node has an individual mempool, and as these contain no transactions that are already in blocks (confirmed transactions), by definition nodes cannot be guaranteed to have agreement about it. So, what you're looking at it blockchain.info's mempool, which may or may not be similar to that of other nodes.

What can cause differences between mempools? One obvious example is in the case of a double spend: no conflicting transactions are allowed in it, so if two distinct transactions which spend the same inputs are broadcast into different places of the network, some will accept one, others will accept the other, based on which they hear first. That's not the only difference, though. Nodes can also have different mempool acceptance policies.

A node's mempool is ultimately its expectation for what transactions may reasonably confirm in the short to medium term. Good mempool acceptance policies are trying to model that expectation. If a transaction's fee is very low, it may not be worth keeping around if there are plenty of higher fee transactions to mine first.

And that is the basis for the mempool DoS protection that was added in Bitcoin Core 0.12. Roughly, whenever the mempool's memory usage goes over a certain preconfigured size (the -maxmempool setting), we kick out the transactions with the lowest feerate, and (temporarily) increase the minimum feerate to get in in the future to that of the evicted ones. That solves the issue of unbounded memory usage.

But what about bandwidth? Things like BIP125 and this eviction described above essentially result in the ability to keep broadcasting transactions, and have them be accepted and replace other transactions, without really paying anything. I say paying here, because the fundamental rule we base mempool policy decisions on is that since we expect transactions in the mempool to confirm, and thus pay their fee. Thus, we'd want a rule that whenever something is evicted from the mempool (for whatever other reason than it confirming), something else pays "something" for that relay. In practice this is accomplished by having a separately configured relay feerate (which does not change when the mempool is full), that specifies the "price" for relay. In the case of mempool eviction, the new transaction(s) must pay at least that relay fee more than the fee of the replaced ones.