Author: Bastien TEINTURIER 2022-01-31 15:57:52
Published on: 2022-01-31T15:57:52+00:00
In a bitcoin-dev mailing list post, Bastien Teinturier proposed new rules for replacing transactions that address limitations of the current BIP 125 rule set. The proposal aims to make it easier to design new rules while improving security and efficiency of multi-party contracts built on top of bitcoin. Teinturier identified several pain points in the current rules, including issues with ancestor absolute fees, non-determinism, and descendant trees, and proposed two simple rules: the transaction's ancestor absolute fees must be X% higher than the previous transaction's ancestor fees, and the transaction's ancestor feerate must be Y% higher than the previous transaction's ancestor feerate. The proposal is incentive compatible and easy to use by wallets, as the ancestor set is easy to obtain and the same in every mempool. However, Teinturier acknowledged that additional rules may need to be added to ensure the proposal is also DoS-resistant.The post discusses the limitations of the current Bitcoin Core RBF policy and aims to start a conversation about how to improve it. It summarizes some ideas that have been discussed and invites new input on issues to be solved and ideas for improvement. The RBF policy currently includes a set of Replace-by-Fee (RBF) criteria that allows the second transaction to replace the first one and any descendants it may have, which can be conflicting unconfirmed transactions. There are three categories/goals: allowing opting out, incentive compatibility, and DoS protection. However, there are several known problems with the current RBF policy. The most pressing concern is that attackers may take advantage of limitations in RBF policy to prevent other users' transactions from being mined or getting accepted as a replacement. There are also user interface issues, such as restrictions on only allowing confirmed UTXOs for funding a fee-bump, which can hurt users trying to fee-bump their transactions and complicate wallet implementations. Additionally, the interface is not suitable for coin selection, and a more helpful interface is needed that helps wallets fund replacement transactions that aim for a feerate and fee. There are some ideas for improvements, including removing Rule #3, making it impossible for a replacement transaction to have a lower mining score than the original transaction(s), and removing Rule #2, which would allow adding new unconfirmed inputs. A different model for fees is also proposed for incentive compatibility, where we can no longer think of it as "the transaction needs to pay for its own bandwidth," since we won't always be getting additional fees. Overall, it is noted that moving to a new set of RBF rules implies rewriting RBF logics and may require a more-or-less long transition period during which both old and new rules will be supported.The Bitcoin community is discussing the problem of transaction replacement by fee (RBF) and how to implement rate-limiting replacements without needing additional fees. One suggestion is to build transaction validation rate-limiting into the P2P layer, instead of the mempool policy layer. Additionally, an incentive compatibility formulation was proposed by Suhas that asks whether the fees expected to be paid in the next N blocks are higher or lower if a transaction is processed. The article explores the concept of mining score for transactions in the mempool and why the current ancestor feerate of a transaction is insufficient to tell what feerate it will be considered at when building a block template in the future. The author suggests several heuristics for estimating mining score and emphasizes the importance of knowing the exact mining priority of unconfirmed transactions.Suggestions for improving RBF include applying current rules only to transactions in the top 0.75MvB-1MvB of the mempool and using a feerate-only rule to eliminate issues associated with absolute fees. However, rate-limiting replacements is still a concern to prevent attacks. The author proposes calculating directly conflicting transactions and their descendants and limiting the total volume to avoid abuse.Finally, the article discusses the need for additional tooling to more accurately assess the economic gain of replacing transactions in the mempool. Suggestions include caching a block template and dividing the mempool into two layers: high and low feerate. Overall, the article provides insights on the complexities of implementing RBF and offers potential solutions to mitigate its drawbacks.The context provided is a list of links and comments related to the development of Bitcoin. These links refer to various GitHub repositories, pull requests, and discussions related to new features and changes to the Bitcoin codebase. One link (#7) refers to a new unconfirmed inputs rule that has been proposed for Bitcoin, which would prevent certain types of transactions from being included in blocks until they have been confirmed.
Updated on: 2023-06-15T16:03:27.842763+00:00