Author: Billy Tetrud 2021-06-17 00:58:22
Published on: 2021-06-17T00:58:22+00:00
Russel O'Connor has suggested that Replace-By-Fee (RBF) should be the default treatment for all Bitcoin transactions instead of being an opt-in/out feature. The author agrees with this proposal, arguing that any configuration in a transaction that has not been committed into a block cannot be relied upon. In addition, miners have an incentive to ignore RBF rules and mine anything that passes consensus, making opting out of RBF a weak defense against theft and a false sense of security. The author questions whether the community wants to support 0-conf payments given the availability of better mechanisms for fast payments like Lightning. Antoine Riard proposes the deprecation of opt-in RBF in favor of full-RBF as the default replacement policy in Bitcoin Core's version 24.0, scheduled for deployment a year from now. This proposal stems from ongoing and anticipated changes in the Bitcoin ecosystem. Opt-in RBF is seen as a DoS vector against multi-party funded transactions, where an attacker can easily disrupt such transactions by propagating an RBF opt-out double-spend of its contributed input before the honest transaction is broadcasted by the protocol orchester. Mempool malicious partitions are another long-term issue that poses a risk, where an attacker exploits network topology or divergence in mempools policies to partition network mempools in different subsets. The author believes that opt-in RBF does not suit the deployment of robust second-layers protocol, even if those issues are still early and deserve more research. At the same time, a meaningful subset of the ecosystem still relies on 0-confs transactions, even though their security is based on far weaker assumptions since opt-in RBF rule is a policy rule, not a consensus one. The author suggests enhancing 0-confs security through proactive security models like double-spend monitoring/receiver-side fee-topping with package relay and reactive security models like economic reputation-based compensations. In conclusion, the proposal to switch to full-RBF is beneficial to some class of already-deployed Bitcoin applications while being detrimental to newer ones. The author suggests preserving the current interests of 0-confs users while enabling upcoming interests of fancy L2s to flourish. If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds too early, the author proposes deferring it to 0.25 or 0.26. The author believes that Core does not have a consistent deprecation process with respect to policy rules heavily relied-on by Bitcoin users, and setting a precedent satisfying as many folks as possible would be ideal.
Updated on: 2023-06-14T22:38:01.611741+00:00