Author: Antoine Riard 2022-10-21 01:50:30
Published on: 2022-10-21T01:50:30+00:00
In a recent Bitcoin Core IRC meeting, the topic of full-RBF deployment methods was widely discussed. Antoine argued that deferring the deployment of full-RBF could be risky for contracting protocols and multi-party applications affected by the pinning DoS vector. He asserted that leaving them exposed to disruptions when their traffic volume would start to be significant would not be ideal. While some stakeholders opposed full-RBF on principle, Antoine believed it was valuable to exchange more perspectives on the subject. Dario Sneidermanis shared different alternatives for the deployment method of full-RBF in his response. He suggested five deployment options with various trade-offs. The gist for these options can be found on Github. Dario also highlighted different dimensions of analysis in terms of the deployment method. These included zero-conf apps immediately affected, predictable deployment date, code complexity, smooth deployment, and time to figure out the right deployment. Dario compared the different deployment options based on the dimensions of analysis. He suggested that Muun could be production-ready with the required changes in six months, but the larger application ecosystem may need more time. For a smooth deployment, Dario proposed locking an activation date in the code and giving relaying nodes enough time to upgrade before activation. In conclusion, the discussion revolved around different alternatives for the deployment method of full-RBF. The stakeholders had different opinions on whether to defer or activate the deployment of full-RBF in the upcoming stable release of 24.0. Different dimensions of analysis were considered in making a decision, such as the impact on zero-conf apps, predictability of deployment, code complexity, smooth deployment, and the time needed to figure out the right deployment method.
Updated on: 2023-06-16T02:19:23.868409+00:00