Mempool Incentive Compatibility

Mempool Incentive Compatibility

Original Postby rustyrussell

Posted on: February 25, 2024 03:56 UTC

A discussion unfolds around the intricacies of transaction policies within a mempool, particularly focusing on the Fee Distribution Policy (FDP) and its implications on incentive compatibility and DoS resistance.

The conversation starts with an acknowledgment of a corrected typo regarding transaction size in a previous post, emphasizing the importance of precision in such technical discussions. The clarity and insightfulness of the original post are praised, highlighting the value of clear communication in complex topics.

The dialogue then delves into the specifics of how FDP might affect the decisions miners make when accepting transactions. It is suggested that in a scenario where the mempool is flat, a miner should favor a smaller transaction offering a higher fee rate over a larger one it could replace, although quantifying this effect presents challenges. Concerns are raised about FDP's potential to decrease incentive compatibility in realistic scenarios compared to the Next Block Policy (NBP), especially considering the total fee rule. Additionally, the conversation touches upon the complexity of DoS resistance, noting that it isn't a binary condition and expressing apprehension about the potential increase in traffic from transactions aggressively replacing each other in the mempool through minimal increments.

Further, the possibility of circumventing the "must pay your way" rule under specific difficult-to-achieve conditions is discussed, suggesting that such exceptions might not significantly impact statistics if managed carefully, for example, by implementing greater hysteresis in transaction acceptance criteria.

A significant concern is raised regarding the absence of consideration for adversarial cases in the current discussion, emphasizing the need for policies that address these scenarios effectively. The limitations of version 3 transactions in supporting Child Pays For Parent (CPFP) in situations of rising fees are critiqued, advocating instead for inline fees and the stacking of multiple transactions to distribute fees more efficiently, potentially utilizing future covenant technology.

Lastly, the discussion speculates on the application of the Feerate Diagram Policy in conjunction with the Next Block Policy for transaction replacements not affecting the top block, suggesting a nuanced approach might be necessary. There's an acknowledgment of an initial assumption about a policy carve-out for certain transactions, which could align with miner incentives and facilitate a simplified Replace-by-Fee (RBF) model. However, evaluating these proposals requires deeper analysis into their DoS potential, incentive compatibility, and effectiveness against adversarial actions, possibly necessitating extensive research or even multiple theses to fully understand their impacts.