delvingbitcoin

Post-clustermempool package RBF: per-chunk processing

Post-clustermempool package RBF: per-chunk processing

Original Postby sdaftuar

Posted on: May 23, 2024 14:35 UTC

The discussion highlights a significant potential issue with the current approach to Replace-By-Fee (RBF) using feerate diagram comparisons, particularly in the context of package RBF.

An attack vector is identified where an adversary could exploit the system by replacing a high-feerate transaction in the mempool with a low-feerate, high-fee transaction that becomes costly to replace due to the total fee test. This scenario involves the construction of a large transaction cluster that may not be optimally linearized by the current heuristics, particularly when part of the transaction graph includes transactions with varying fees.

In the described attack, the adversary constructs a complex transaction setup where a low-fee transaction within a big cluster leads to two high-fee transactions. This setup might not be easily identified as a significant chunk for linearization due to heuristic limitations. However, by adding another transaction that spends from these high-fee transactions at a low feerate but introduces a new transaction with a slightly higher feerate that conflicts with an existing high-feerate transaction in the mempool, the attacker manipulates the system. The addition of this new transaction potentially improves the overall feerate diagram of the cluster, making the replacement of the original high-feerate transaction with the adversarial transaction viable.

This strategy exploits two main aspects: the ability to run the linearization algorithm an additional time, potentially finding a better linearization that favors the new transaction over the existing one, and the limitations of the linearization algorithm itself. By intentionally creating a transaction cluster that linearizes poorly under current heuristics but improves with the addition of a new leaf transaction, the attacker can manipulate the outcome to their advantage.

The issue also extends to concerns about the feasibility of addressing this problem within single-transaction RBF scenarios, suggesting that simply requiring a new transaction's chunk feerate to surpass its conflicts might not provide a viable solution in package RBF settings without imposing overly strict limitations. This complex challenge underscores the need for further exploration and potential adjustments in RBF strategies to mitigate such adversarial tactics effectively.