Published on: 2021-12-20T02:30:57+00:00
The Bitcoin community is currently engaged in a discussion about the future of 0-conf transactions and how to address the associated security risks. One proposal that has been put forward is to deprecate opt-in Replace-by-Fee (RBF) and replace it with full-RBF as the default replacement policy in Bitcoin Core version 24.0. The rationale behind this proposal is to mitigate the risk of denial-of-service (DoS) attacks on multi-party funded transactions enabled by RBF opt-out. These attacks can occur when a malicious counterparty broadcasts a low-feerate, opt-out spending of its own collateral input before engaging in cooperative funding, leading to a DoS situation.Another concern is the risk of mempool malicious partitions, where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets. Opt-in RBF serves as a low-cost partitioning tool, which nullifies most potential progress to mitigate such malicious partitioning. To address these issues, it has been suggested to gradually transition away from full-RBF by enforcing non-replaceability n seconds after the first seen transaction. The goal is to reduce the ability to partition mempools by broadcasting irreplaceable conflicts all at once.In terms of enhancing the security of 0-conf transactions, proactive and reactive security models have been proposed. Proactive models include double-spend monitoring and receiver-side fee-topping with package relay, while reactive models involve economic reputation-based compensations. These approaches aim to detect and respond to successful double-spend attempts and ensure the integrity of 0-conf transactions.The discussion also highlights the need to balance the interests of existing 0-conf users and the development of Layer 2 solutions. While some argue for the preservation of 0-conf transactions, others believe that enabling upcoming interests of fancy Layer 2 solutions is crucial. The decision to switch to full-RBF may be deferred to future updates if it is deemed too early.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 proposal is motivated by ongoing and anticipated changes in the Bitcoin ecosystem. One issue with opt-in RBF is that it doesn't suit the deployment of robust second-layer protocols, and opt-out RBF can be used as a Denial-of-Service (DoS) vector against multi-party funded transactions and mempool partitions.There are 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 service 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-conf 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-conf users while enabling upcoming interests of fancy Layer 2 solutions to flourish. If there is agreement on switching to full-RBF, but 0.24 sounds too early, it can be deferred to 0.25 or 0.26.The bitcoin-dev mailing list has been discussing the adoption of RBF as a standard treatment for all transactions, rather than an opt-in/out feature. Some members believe that opting out of RBF is a weak defense and could lead to theft events. However, there are concerns that eliminating opt-in RBF could affect users who rely on 0-conf payments, which are based on far weaker assumptions. The use of 0-conf payments is still unclear, and it is uncertain how often they are used in the Bitcoin ecosystem at this point.One issue with opt-out RBF is that it allows attackers to perform DoS attacks against multi-party funded transactions by propagating an RBF opt-out double-spend of its contributed input before the honest transaction is broadcasted by the protocol orchestra. This can waste the time value of the victim's inputs or force exhaustion of the fee-bumping reserve.
Updated on: 2023-08-02T04:01:48.545744+00:00