The core of the issue revolves around how transactions with conflicting inputs are handled. For illustration, a scenario was presented using the mermaid flowchart syntax to depict three transactions: TxA with a fee of 0 satoshis and size of 300 vbytes, TxB with a fee of 11,780 satoshis and size of 130 vbytes, and TxC, which conflicts with TxB, carrying a fee of 10,000 satoshis and a size of 384 vbytes.

The transaction package consisting of TxA plus a pure burn of 10,000 satoshis yields a rate of 27 sat/vbyte, which is identical to the package rate of TxA+TxB. However, including TxB also accomplishes the eviction of TxC, suggesting that counterparties in such transactions have extra incentives to increase this rate.

A potential solution to simulate these conflicts more accurately might involve implementing the checks during the actual execution phase, allowing Replace-by-Fee (RBF) logic to manage them after transactions have been clustered in the mempool. Prior to clustering, it may be more straightforward to initiate the process with outputs valued at zero. This approach would effectively address the issue without relying on a full diagram check to mitigate incentives for value inflation within the mempool.