Analysis of full-RBF deployment methods

Summary:

In this email exchange, Dario is thanking Antoine for taking the time to reply to his emails with detailed analysis. Antoine had raised concerns about deferring full-RBF deployment and suggested that it was not a risk-free option for the contracting protocols and multi-party applications affected by the pinning DoS vector. He believes that such use cases were mostly vaporware a year ago but have now become a tangible reality with new things like ln-vortex, Phoenix wallet, and some LDK users planning to use dual-funded soon.To solve the attack described in [0], collaborative transaction protocols (such as dual-funded channels) need a reliable way to replace transactions. Otherwise, protocol parties using full-RBF may see replacements succeed in their own mempool, only to find out they weren't relayed to a miner once it's too late. Even if we deployed opt-out (or mandatory!) full-RBF now and miners adopted it immediately, it would take almost a year for it to be sufficiently deployed in the relaying layer to be considered reliable. Antoine suggests that #26323 (option 5 in the OP) has the advantage of getting us to a reliable full-RBF network the fastest while not threatening zero-conf applications until the activation time. That is, #26323 gives us a way in which we don't need to choose between the security of one use case versus the other. We can have both. Regarding the interdependency between network policy rules and business risk, Antoine says that he doesn't know if it should be the responsibility of developers to solve every operational risk encumbered by a Bitcoin business, like FX risk. However, he thinks that asking for a predictable deployment timeline for a change that would put some applications at increased risk could be described as burdening the developers with solving every operational risk. This deployment method comparison's goal was precisely to soften the burden on core devs.

Updated on: 2023-06-16T02:18:57.369726+00:00