Author: Greg Sanders 2021-06-17 22:28:45
Published on: 2021-06-17T22:28:45+00:00
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 time value of victim's inputs or force exhaustion of the fee-bumping reserve. Another problem with opt-out RBF is the risk of mempools malicious partitions where an attacker exploits network topology or divergence in mempools policies to partition network mempools in different subsets. To enhance 0-conf security, reactive security models such as economic reputation-based compensations can be employed. If a double-spend has been qualified, service providers can slash the service account of the sender if already known, or rely on "side-trust" models if the sender is a low-trusted counterparty to the merchant. Proactive security models such as double-spend monitoring or receiver-side fee-topping with package relay can also be deployed. In conclusion, the community should consider preserving the current interests of 0-confs users while enabling upcoming interests of fancy L2s to flourish. If there is agreement on switching to full-RBF, but 0.24 sounds too early, let's defer it to 0.25 or 0.26.
Updated on: 2023-06-14T22:35:36.207829+00:00