Cluster mempool partitioning attacks

The discussion revolves around the intricacies of requiring chunking or linearization in transaction replacements, particularly in scenarios involving Replace-By-Fee (RBF) mechanisms. One argument against mandating this requirement is the potential for bandwidth wastage. In most cases, nearly 99.9% of the time, hints for transaction replacement are not necessary, leading to questions about the efficacy and necessity of sending such information. The contention lies in determining the appropriate circumstances under which this data should be transmitted.

In the specific context of RBF, where transactions are replaced during relay due to time constraints, the utility of linearization comes into sharper focus. Contrary to some beliefs, a more effective linearization strategy could potentially prevent a transaction from being evicted or even expedite its inclusion in a block. While the limitations and challenges with RBF are acknowledged, they do not encompass the entirety of the issues at hand. For instance, an attacker could inhibit the relay of any RBF transaction within a given cluster by ensuring that none of the transaction versions required for improvement are known. This highlights a broader issue: wallets may not have knowledge of mempool contents, nor can one assume consistency between different mempools.

The essence of the debate is finding a balance between redundancy and efficiency. It's not about having intimate knowledge of all possible transaction variants but about relaying a package with sufficient linearization information to be effective when necessary. The challenge lies in devising a solution that avoids the need for sending entire transaction clusters redundantly while remaining practical for the rare occasions it's needed. This underscores the complexity of optimizing transaction relay processes without imposing undue burdens on network resources.