Author: Antoine Riard 2022-12-06 04:06:34
Published on: 2022-12-06T04:06:34+00:00
In this email exchange, Antoine Riard responds to John Carvalho's thoughts on the "mempoolfullrbf" feature in Bitcoin Core. Antoine acknowledges the complexity of the topic and the potential impacts on various use-cases such as on-chain payments, Lightning, and coinjoins. He states that he can only speak for himself based on his experience contributing to Bitcoin Core and other open-source projects.Antoine discusses the decision-making process for removing features from Bitcoin Core, which should follow the same process as any code change. He notes that the ecosystem impact and utility are factors that can be considered in the evaluation of the soundness of a change. With regard to "mempoolfullrbf," Antoine acknowledges the potential benefits for wallets and multi-party applications/contracting protocols, but also sees a lowering of the technical bar for accomplishing a double-spend.During the discussion, a mempool policy design philosophy was proposed to accommodate all Bitcoin use-cases alive on the network while not harming the network interests. However, there is still the open question of whether this philosophy is sound enough in the face of miner incentives and won't generate asymmetries in mining incomes.Antoine believes that removing the "risk-induction" `mempoolfullrbf` feature is better for the ecosystem, given the altering of security expectations for 0conf operators. He suggests that more merchants/service operators producing effective usage data would be valuable. Antoine acknowledges that anyone can create and distribute patches for any given mempool policy, regardless of whether it is removed from Core. However, he argues that mempoolfullrbf removes the user choice of zero-conf services and positions Core as a political authority and influencer.GAP600 is a zero-conf risk analysis business that is integrated and leveraged by payment processors/liquidity providers and merchants. However, the deployment of fullrbf by enough full-node operators and a subset of the mining hashrate would lower the cost of double-spend attack by lambda users, therefore increasing the risk exposure of GAP600's users. This increased risk exposure could lead to an alteration in the acceptance of incoming zero-conf transactions.On the topic of statistics, Antoine has asked for clarification on how many transactions are Bitcoin-only, how many are excluded from zeroconf due to factors like RBF, long-chain of unconfirmed ancestors or too high-value, and what the average feerate is. Antoine notes that his personal position on fullrbf is still the same as expressed in #26525. As a community, there is no conceptual consensus on deploying full-rbf nor removing it.To remove the current option from Bitcoin Core, he believes the prerequisite to address are the qualification of enough economic flows at risk and the presence of a sizable loss in miners income. Furthermore, he believes there is still the open question of whether the Bitcoin protocol development community should restrain user choice in policy settings in the name of preserving mining income and established use-case stability.The original technical motivation of this option, and the wider smoother deployment was to address a DoS vector affecting another class of use-case: multi-party transactions like coinjoin and contracting protocols like Lightning. All of them expect to generate economic flows and corresponding mining income. Since then, alternative paths to solve this DoS vector have been devised, all with their own trade-offs and conceptual issues.
Updated on: 2023-06-16T03:20:12.195691+00:00