An overview of the cluster mempool proposal

When assessing the potential eviction of transaction B to accommodate transaction C, it is observed that even if making space for C by removing B and its descendants is a valid move under the fee rate checks, there's a possibility that B could be immediately re-accepted into the mempool. This scenario arises because B, without its descendant D, might no longer exceed the cluster size limits. This process leads to a progression through various mempool states, each improving the fee rate diagram, which is generally seen as a positive outcome.

However, concerns arise regarding the efficiency and security implications. Specifically, the transaction B may end up being relayed and validated twice, leading to unnecessary redundancy and potential waste of resources. This inefficiency could potentially be exploited for denial-of-service attacks if an adversary can easily create many such pairs of transactions like C and D.

To mitigate this issue, it has been suggested that a more direct transition from the state "[E, B, D] [A]" to "[E, A, C, B]" would be ideal, bypassing the intermediate stage where B is temporarily evicted. One possible solution could involve leveraging the existing linear order of transactions slated for eviction, for instance, "[..B, D]", and attempting to re-add these transactions back to the mempool in their original sequence without delay. This approach could streamline the process and prevent the double handling of transaction B.