Global Bitcoin transaction relay rate limiting

[Antidote47k]

Bitcoin core recently merged a change that replaces its previous per peer transaction relay rate limiting with a global approach. Previously, it maintained a separate queue of transaction announcements for each peer which were continuously sorted by transaction priority, each peer had a relay limit of about 7 transactions per second which works fine normally, but then a sudden burst of transactions could make the queue grow faster than they could drain and since the queues were repeatedly sorted as new transactions arrives, this could potentially result in excess use of CPU and become a DoS vector.

The new approach uses global token buckets based on:

• transaction count
• serialized transaction size

If the capacity is not enough then the transactions are placed into a global backlog which prevents independent queues from growing without the same global control, then transactions are selected in accordance to their priority  and then placed into small per peer queues for relay.

What’s interesting is that this didn’t simply put a smaller limit on the old queues but also changed how the node manages it overall relay resources. It also shows that DoS protection isn’t always about rejecting malicoius or invalid data, but even legitimate looking network activity can become a problem if a node is forced to spend too many resources processing it.

[hmbdofficial]

I think this is a good development because it should fix the weaknesses in how transaction relay resources were managed, rather than simply reducing the old per- peer limit.

What I also find most interesting is the DoS lesson here. An attacker doesn’t necessarily need to send invalid transactions to stress a bitcoin node. Even valid transactions can become a problem if they cause disproportionate CPU, memory or bandwidth consumption. So in my opinion, this is a good example of bitcoin core improving DoS resistance through better resource management rather than simply rejecting more transactions. It should make relay behaviour more predictable under abnormal traffic bursts while preserving normal propagations.

[Danish Ali]

Important thing to note is that it is not just reducing the size of the mode of failure, an attacker could give a lot of queues and overload each one individually and failure mode was the re-sorting that occurred across all queues and was the cause of the CPU hit -- the old per peer queues are still separated.

This is not like multiple flooding connections was, stressing the old queue design; unlike that one there is a limit per peer going in, but unlike multiple flooding connections one spamming peer can not eat away into other peers' capacity, it cannot diminish capacity except for invalid transactions in the backlog. This is not really a trade off for fairness, it is more of a fix for the fact that there is a loophole making the per-peer isolation ineffective in practice.