Author: Bastien TEINTURIER 2022-02-07 10:22:01
Published on: 2022-02-07T10:22:01+00:00
Bitcoin Core's Replace-by-Fee (RBF) policy allows for the replacement of conflicting unconfirmed transactions, but there are limitations to the current policy that need to be addressed. One major concern is pinning attacks, where an attacker can prevent other users' transactions from getting mined by taking advantage of RBF policy limitations. The proposed improvements include requiring the ancestor score of the replacement transaction to be at least 5%, 10%, or N% higher than that of every original transaction and requiring the replacement's feerate to be higher than the maximum mining score of transactions left in the mempool after the next block. Another limitation is the requirement for replacement transactions to increase the absolute fee of the mempool, which has been criticized as "bonkers." This poses a problem for Lightning Network (LN) channels, where commitment transactions may not have high priority by miners due to a full mempool. The solution is to enable a fair feerate bid between counterparties to force adversaries to overbid or disengage from the competition. To improve RBF policy, proposals include using a feerate-only rule instead of the absolute fee requirement for transactions below a certain size in the mempool, rate-limiting how many replacements are allowed per prevout, and rate-limiting transaction validation per peer. However, there are concerns about introducing new pinning vectors and the need to ensure incentive compatibility and DoS protection. The goal is to create a replacement policy that results in a useful interface for users and safe policy for node operators. There is also a need for a transition period during which both old and new RBF rules are supported.In a Bitcoin-dev email thread, Bastien Teinturier proposes new rules for replace-by-fee (RBF) in Bitcoin transactions. The proposed rules would require that the transaction's ancestor absolute fees be X% higher than the previous transaction's ancestor fees and the transaction's ancestor feerate be Y% higher than the previous transaction's ancestor feerate. These rules are easy to use by wallets, and an important point is that the ancestor set is the same in every mempool, whereas the descendant set is not. The descendants will be re-submitted and mined as well, so their fees aren't lost.However, it is unclear if these rules are DoS-resistant, so Bastien suggests adding a third rule to address that. Bastien also believes that the BIP 125 rule 2 is unnecessary and should be removed as there's no good reason to keep it. Rule 3 prevents efficient use of capital while it's unconfirmed. In order to be capital-efficient, one will end up creating descendant trees for time-sensitive transactions. However, replacing all children will cost an absurdly large amount of fees. The article discusses several issues with Bitcoin's Replace-by-fee (RBF) policy and proposes changes to the RBF rules. One proposed change is to remove Rule #3, which requires the replacement to pay higher absolute fees than the original, and instead rate-limiting replacements based on expected fees in the next N blocks. Another proposed change is to eliminate the SIGHASH_ANYONECANPAY pinning attack by making it impossible for a replacement transaction to have a lower mining score than the original transaction(s). The article also suggests creating a more user-friendly interface that helps wallet fund replacement transactions at a specific feerate and fee, as well as updating the mempool and mining logic to better handle RBF.Bitcoin developers are working on improving the Replace-by-fee (RBF) protocol, which allows users to replace an unconfirmed transaction with a new one that includes higher fees. Possible solutions for rate-limiting the number of replacements allowed per prevout and transaction validation per peer have been discussed. One approach suggested is to use a feerate-only rule, but concerns about how to rate limit replacements have been raised. Another proposed solution involves dividing the mempool into two layers: "high feerate" and "low feerate" and using a Knapsack algorithm at the edge of a block to determine which transactions should be included. The proposed improvements incorporate suggestions, grievances, criticisms, and ideas from several Bitcoin developers. Possible implementation tooling was also discussed, including calculating block templates on the fly or caching them, keeping track of the feerate of transactions left over, and dividing the mempool into two layers.
Updated on: 2023-06-15T15:54:18.601514+00:00