On mempool policy consistency

Summary:

The author of this message discusses the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of "to each use-case belongs a set of transaction-relay policy rules" is explained, which aims to provide specific policy rules for each use-case that can ensure non-replacement guarantees to consumers of transactions signaling under this regime.However, there are concerns about potential interference between different sets of policy rules or discrepancies between policy rule designs and miners' incentives leading to informational asymmetries harmful to the long-term decentralization of the mining ecosystem. Moreover, the lack of a well-understood miner incentive model makes it difficult to evaluate the soundness of a set of policy rules. The author argues that a better quantitative understanding of so-called "miners incentives" is required to pursue further in the paradigm of "to each use-case belongs its set of policy rules." There is also a discussion on the benefits of enabling fullrbf on the network. The article discusses the concept of opt-in Replace-By-Fee (RBF) and full RBF policies in Bitcoin transactions. The author argues that while a maximal RBF policy might be useful, it is not currently feasible due to limitations of transaction relay and issues with incentive compatibility. Additionally, the author questions the need for a full RBF policy when users already have the ability to choose whether or not to subject their transactions to RBF. The article also explores the idea of non-replacement policies and the potential benefits they could offer to certain use cases such as zeroconf or better fee bumping behavior. The author posits that offering an opt-in non-replacement policy would not interfere with other network protocols or anti-DoS mempool acceptance algorithms.The author draws a comparison to the proposed v3 transaction policy and argues against the idea of allowing users to disable it, stating that doing so would be subversive to making the lightning use case for v3 transactions work. Suhas Daftuar, a Bitcoin Core developer, recently shared his opposition to the full Replace-By-Fee (fullrbf) network policy, which would allow users to replace unconfirmed transactions with higher fee versions. He argues that while fullrbf may have benefits, it also breaks zeroconf business practices and could potentially lead to incentive incompatibility issues. His philosophy is to support disparate use cases to make everything work better, rather than prematurely breaking things because others might do so eventually.Daftuar poses several questions to those who favor fullrbf, including whether it offers any benefits beyond breaking zeroconf practices, whether enforcing BIP 125's rbf rules on all transactions is reasonable if they are not always incentive compatible, and whether opposing future command line options that break v3 transaction relay is consistent with moving towards fullrbf. He notes that chaining unconfirmed transactions when the sender might RBF the parent is riskier, as it creates pinning issues for the sender and risks having the child wiped out if the parent is replaced. Signaling that a transaction won't be replaced could therefore be useful. Additionally, he acknowledges that v3 transactions may not create an unreasonable security assumption for their intended use case, but there is a possibility that someone could adopt a usage pattern that subverts the intent of the policy. Daftuar's email can be found on the bitcoin-dev mailing list archive [2]. He also references BIP 125 [3], which outlines the rules for replace-by-fee transactions, and a lightning-dev email [1] discussing the potential impact of fullrbf on Lightning Network payments. The author concludes by stating that, while there may be arguments both for and against non-RBF signaling transactions, there is currently no pressing need to offer software that might break a policy that is working well for some users.

Updated on: 2023-06-16T02:30:53.913303+00:00