With respect to the disagreement/misunderstanding about the
"<1vMB in the mempool" case, I think it's important to be clear about what the goals of relay policy are. Should the goal be to only relay transactions that increase miner revenue? Sure ideally, because we want to minimize load on the network. But practically, getting that goal 100% probably involves tradeoffs of diminishing returns.
The only way to ensure that a transaction is only relayed when it increases miner revenue is to make relay rules exactly match miner inclusion rules. And since we don't want to (nor can we) force miners to do transaction inclusion the same as each other, we certainly can't realistically produce an environment where relay rules exactly match miner inclusion rules.
So I think the goal should not be strictly minimal relay, because it's not practical and basically not even possible. Instead the goal should be some close-enough approach.
This relates to the
"<1vMB in the mempool" case because the disagreement seems to be related to what trade offs to make. A simple rule that the fee-rate must be bumped by at least X satoshi would indeed allow the scenario darosior describes, where someone can broadcast one large low-feerate transaction and then subsequently broadcast smaller but higher-feerate transactions. The question is: is that really likely be a problem? This can be framed by considering a couple cases:
* The average case
* The adversarial worst case
In the average case, no one is going to be broadcasting any transactions like that because they don't need to. So in the average case, that scenario can be ignored. In the adversarial case however, some large actor that sends lots of transactions could spam the network any time blockchain congestion. What's the worst someone could do?
Well if there's really simply not enough transactions to even fill the block, without an absolute-fee bump requirement, a malicious actor could create a lot of spam. To the tune of over 8000 transactions (assuming a 1 sat/vb relay rule) for an empty mempool where the malicious actor sends a 2MB transaction with a 1 sat/vb fee, then a 1MB transaction with a 2 sat/vb, then 666KB transaction for 3 sat/vb etc. But in considering that this transaction would already take up the entire block, it would be just as effective for an attacker to send 8000 minimal sized transactions and have them relayed. So this method of attack doesn't gain the attacker any additional power to spam the network. Not to mention that nodes should be easily able to handle that load, so there's not much of an actual "attack" happening here. Just an insignificant amount of avoidable extra spent electricity and unnecessary internet traffic. Nothing that's going to make running a full node any harder.
And in the case that there *are* enough transactions to fill the block (which I think is the normal case, and it really should become a rarity for this not to the case in the future), higher feerate transactions are always better unless you already overpaid for fees. Sure you can overpay and then add some spam by making successively higher feerate but smaller transactions, but in that case you've basically paid for all that spam up front with your original fee. So is it really spam? If you've covered the cost of it, then its not spam as much as it is stupid behavior.
So I'm inclined to agree with O'Beirne (and Lisa Neigut) that valid transactions with feerate bumps should never be excluded from relay as long as the amount of the feerate bump is more than the node's minimum transaction fee. Doing that would also get rid of the spectre of transaction pinning.
I'm curious if there's some other type of scenario where removing the absolute fee bump rule would cause nodes to relay more transactions than they would relay in a full/congested mempool scenario. We shouldn't care about spam that only happens when the network is quiet and can't bring network traffic above normal non-quiet loads because a case like that isn't a dos risk.