Cluster Mempool RBF Thoughts

In scenarios where clusters C2 to C5 are not visible but P11 to P99 are, a direct RBF from C1 to C6 would incorrectly appear as if it's merging an excessively high number of clusters, surpassing the allowed limit. This highlights the problematic nature of the current system, which is overly dependent on the order of operations and can be affected without any malicious interference.

To refine the process and manage its complexity, a new metric is proposed. Instead of focusing on the number of affected clusters, the suggestion is to consider the total number of transactions within these clusters. The criterion for evaluating an RBF could be whether the number of affected transactions remains under 2,500. This adjustment aims to accommodate straightforward Child-Pays-For-Parent (CPFP) patterns up to the cluster limits while maintaining a check on the scope of diagramming required for assessment.

However, even with this proposed metric, there remains a risk in adversarial scenarios. A potential attacker could exploit the RBF/CPFP mechanism by manipulating around 25 separate clusters, assuming each bumped transaction is part of a cluster at maximum capacity. This leaves room for further contemplation on how to secure the transaction process against such vulnerabilities.