Proposal: Full-RBF in Bitcoin Core 24.0



Summary:

The proposal to deprecate opt-in Replace-by-Fee (RBF) in favor of full-RBF as the default replacement policy in Bitcoin Core version 24.0 has been put forward by Antoine Riard. This is because ongoing and anticipated changes in the Bitcoin ecosystem are motivating this proposal. One of the issues with opt-in RBF is that it doesn't suit the deployment of robust second-layers protocol, and opt-out RBF can be used as a Denial-of-Service (DoS) vector against multi-party funded transactions and mempool partitions vector. The proposal raises questions about whether the community wants to support 0-conf payments at this point, given that there are better mechanisms for fast payments such as Lightning. While few services providers are offering zero-conf channels, where you can start to spend instantly, the security model of 0-conf is far weaker than other payment models. However, there are some Bitcoin services well-known to rely on 0-conf, but beyond how much of the Bitcoin traffic is tied to 0-conf is a hard question. Furthermore, it's not clear how software generally informs the user about 0-conf payment detection, though typically, it's something like an "Unconfirmed" annotation on incoming transactions. To enhance 0-confs security, double-spend monitoring/receiver-side fee-topping with package relay and economic reputation-based compensations are some approaches that could be considered. Overall, the proposal highlights the fact that a transaction relay/mempool acceptance policy might be beneficial to some class of already-deployed Bitcoin applications while being detrimental to newer ones. It is essential to preserve 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, it can be deferred to 0.25 or 0.26.


Updated on: 2023-06-14T22:35:55.131254+00:00