Author: Michael Folkson 2022-02-05 13:21:57
Published on: 2022-02-05T13:21:57+00:00
In a message posted to the Bitcoin-dev mailing list, Bastien Teinturier expressed concerns around replaceable transactions fee bumping and how it affects multi-party contracts on Bitcoin's Lightning network. Specifically, he highlighted issues with BIP 125 rules 2 and 3, which contribute to unnecessary complexity and inefficiency in transaction fees. While acknowledging the original rationale behind these rules, Bastien proposed new and simplified rules that prioritize DoS protection and incentive compatibility. He also touched on the need for a clear user interface for RBF policies in L2 protocols, given potential vulnerabilities in attackers triggering policy-invalid chains of transactions.Bitcoin Core's Replace-by-Fee (RBF) policy has a number of limitations that need to be addressed. The current RBF policy includes a set of criteria that allows the second transaction to replace the first one and any descendants it may have. However, there are concerns over pinning attacks, where attackers may take advantage of limitations in RBF policy to prevent other users' transactions from being mined or getting accepted as a replacement. One such limitation is the requirement for replacement transactions to increase the absolute fee of the mempool. Another issue is that the restriction of requiring confirmed UTXOs to fund a fee-bump can hurt users trying to fee-bump their transactions and complicate wallet implementations.In order to address these issues, Bitcoin developers have proposed various solutions. These include turning off the "replace-by-fee" behavior as soon as the mempool is fulfilled with a few blocks, rate-limiting how many replacements are allowed per prevout, and rate-limiting transaction validation in general, per peer. There is also a proposal to pick up constants scaled on the block size to deter attackers from launching an attack. However, there is a concern about introducing new pinning vectors in the context of shared-utxo.The Bitcoin Replace-by-Fee (RBF) feature is being improved upon to make it more user-friendly and secure. The current design violates several rules, including refusing to increase transaction fees for replacements and allowing new inputs. These issues have been addressed in several proposals focused on rate-limiting the number of replacements per previous output and limiting transaction validation per peer. Feerate-only approaches are also under consideration, with suggestions that the replacement's feerate must be higher than the maximum mining score of remaining mempool transactions after one block.The Bitcoin development team has been discussing the need for additional tooling to accurately assess economic gain when replacing transactions in the mempool. Three options have been suggested, including calculating block templates on the fly, keeping a persistent block template, or dividing the mempool into two layers based on feerate. The team also acknowledges contributions from various individuals in the development process, including Andrew Chow, Matt Corallo, and Lloyd Fournier. Links to related pull requests and discussions are provided in the context.Despite the proposed solutions, there is still the issue of deployment to warn of. Moving to a new set of RBF rules implies for a lot of Bitcoin applications to rewrite their RBF logics, so a more-or-less long transition period may be necessary during which both sets of rules are supported.
Updated on: 2023-06-15T15:58:55.996771+00:00