Published on: 2022-11-10T14:38:27+00:00
The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases.
Updated on: 2023-08-02T08:19:04.219216+00:00