Published on: 2022-10-23T23:10:16+00:00
In an email exchange between Antoine Riard and Dario Sneidermanis, they discuss the risks and benefits of implementing a full-replace-by-fee (RBF) deployment on the Bitcoin network. Antoine expresses concerns about potential disruptions to contracting protocols and multi-party applications, while Dario argues that a reliable full-RBF network is necessary to prevent pinning denial-of-service attacks. They agree that option 5 in the original post would be the best approach for achieving a reliable full-RBF network without threatening zero-conf applications until the activation time.Antoine suggests that May 1st, 2023, may be too early for full-RBF deployment and proposes a timeline of 10-12 months instead. He also emphasizes the need for better communication channels between business/service operators and protocol developers to clarify functional responsibilities. However, he does not believe that it should be solely the responsibility of developers to solve every operational risk faced by Bitcoin businesses.Dario counters Antoine's argument by stating that requesting a predictable deployment timeline for a change that increases the risk for certain applications should not be seen as burdening the developers. The goal of comparing deployment methods was to alleviate some of the burden on core developers.In their email exchange, Dario thanks Antoine for his detailed analysis and acknowledges Antoine's concerns about deferring full-RBF deployment. Antoine believes that the pinning DoS vector poses a risk to contracting protocols and multi-party applications. He mentions new developments such as ln-vortex, Phoenix wallet, and LDK users planning to use dual-funded soon, which have made these use cases more tangible.To address the attack described in [0], collaborative transaction protocols require a reliable way to replace transactions. Antoine suggests that option 5 (#26323) provides the fastest path to a reliable full-RBF network without endangering zero-conf applications. He believes that both security and zero-conf applications can coexist with this approach.Antoine raises the issue of interdependency between network policy rules and business risk, questioning whether developers should be responsible for every operational risk faced by Bitcoin businesses. Dario argues that asking for a predictable deployment timeline for a change that increases risk should not be seen as burdening the developers.In a recent Bitcoin Core IRC meeting, full-RBF deployment methods were extensively discussed. Antoine argues that deferring full-RBF deployment could be risky for contracting protocols and multi-party applications affected by the pinning DoS vector. He believes it is important to exchange different perspectives on this subject. Dario presents various alternatives for the deployment method of full-RBF and suggests five deployment options with different trade-offs. The details for these options can be found on Github. Dario compares the options based on dimensions such as immediate impact on zero-conf apps, predictability of deployment date, code complexity, smooth deployment, and time to figure out the right deployment.The stakeholders have differing opinions on whether to defer or activate full-RBF deployment in the upcoming stable release of version 24.0. They consider various dimensions of analysis to make a decision, including the impact on zero-conf apps, predictability of deployment, code complexity, smooth deployment, and the time required to determine the appropriate deployment method.With the impending release of version 24.0, a decision needs to be made regarding the deployment method of full-RBF. Several alternatives have been documented, each with its own trade-offs. These options include leaving the current version as is and merging opt-out in later versions, reverting opt-in full-RBF to allow more time for planning, and committing to a later date for opt-out activation. It is noted that once fully deployed, having a configuration option to disable it could be problematic.The analysis considers various dimensions, such as the impact on zero-conf apps, predictability of deployment date, code complexity, smooth deployment, and the time needed to determine the appropriate method. The comparison provides an overview of different approaches to address these dimensions. Regarding the timeline for full-RBF activation, Muun could be ready in six months with the necessary changes, while the larger application ecosystem may require more time for understanding the impact, designing solutions, implementing them, and deploying them. A smooth deployment can be achieved by setting an activation date in the code and allowing sufficient time for relaying nodes to upgrade before activation. Assuming uniform adoption distribution, two release cycles may be enough to achieve 61% adoption.
Updated on: 2023-08-02T08:17:08.125992+00:00