Back in 2015, Bitcoin Core introduced in PR6722 a concept of “rolling minimum fee policy”, where in the case of full mempool, the minimum acceptance fee would be set to the fee of a transaction that was evicted.
However, this fee would not be reset on finding a new block, but decay over time. This appears to be a DoS measure. morcos has a good comment on the logic behind it and did the math behind this policy in this comment.
Future transactions should be obligated to pay for the cost of transactions that were evicted (and their own relay fee) otherwise a large package of transactions could be evicted by a small tx with a slightly higher fee rate. This could happen repeatedly for a bandwidth attack.
It appears this code is still present in the codebase of BCHN.
This is not a big issue on BTC, where transactions are expected to be unreliable. However, on BCH, it is assumed that low-fee transactions will be accepted within reasonable time. I do believe both popular wallets, as well as smart contracts (especially covenant contracts) hard code fees in their client due to this assumption. This decay is not well known and will probably cause surprises if it takes effect.
I speculate it is possible to flood the mempool to bump the fee floor, and while waiting for the decay to take effect:
- Users will be confused to see their transactions be rejected, even though mempool is not full.
- It will more plausible to do 0-conf double spends due to other nodes not having this decay.
Is this a problem? How would we mitigate the DoS vector described by morcos if we were to remove the decay?