Published on: 2022-03-17T15:59:11+00:00
In recent discussions among Bitcoin developers, proposals have been made to improve the Replace-by-Fee (RBF) policies in the mempool. The goal is to address limitations and potential vulnerabilities of the current rules. One suggestion is to implement transaction relay rate limiting with a feerate-based priority queue and staggered broadcast of replacement transactions. This would prioritize transactions based on their likelihood of being included in a block.Another proposal is to allow users to specify descendant limits on their transactions, which would help solve the pinning problem associated with package RBF attacks.There has also been discussion around the concept of "mining score" as a way to prioritize transactions. The mining score would be calculated based on the ancestor feerate at which a transaction is included in a block. It is suggested that this mining score could be used as the priority value for transaction relay if a rate-limited priority queue is implemented.Some concerns have been raised about the potential downsides of these proposals, but they have generally been well-received and open for feedback. The overall objective is to prevent Denial-of-Service (DoS) attacks while maintaining the fee-rate relay rule that already mitigates spam.The conversation also touches on the idea of excluding low fee transactions from being relayed and included in blocks. While there are concerns about missing out on good fees, it is noted that this approach is a special case and other factors need to be considered, such as trusting that a lower fee transaction won't replace a higher fee transaction and the number of transactions bidding for a spot in the next block.Rate limiting is already done via INVENTORY_BROADCAST_MAX and *_INVENTORY_BROADCAST_INTERVAL, but an alternative approach suggested is to track the "effective fee rate" to better manage the ancestor fee rate. This could be achieved through candidate set blockbuilding ideas.Furthermore, there has been discussion about keeping high-feerate evicted transactions in the mempool in case they get mined by someone else, which could improve compact block relay. However, concerns have been raised about the sufficiency of the 100 transaction LRU cache and the possibility of applying rate limits only to replacement transactions.Lastly, there is a suggestion to have a split between mempool acceptance rules and spam prevention rules. This would allow transactions to be sent to miners through an alternate route if they are blocked by anti-spam rules.Overall, the discussions focus on improving the RBF policies in Bitcoin's transaction relay system to address limitations, prevent DoS attacks, and ensure a fair and efficient fee-based transaction prioritization.In another discussion, participants considered whether or not descendants matter for miner incentives. The group also discussed policies to address miner incentives and DoS issues, such as requiring certain percentage increases in ancestor absolute fees and feerates. The conversation highlights the need for improved security and more efficient use of resources in multi-party contracts built on top of Bitcoin.Bastien Teinturier proposes new rules for replacing transactions that prioritize DoS protection and incentive compatibility. He suggests separating policies that address miner incentives from policies that address DoS issues and adding a third policy to specifically address DoS concerns. He also discusses the timeline for implementing updated policies and potential vulnerabilities in multi-party contracts due to reliance on policies that cannot be enforced.Another member of the mailing list suggests relay rate limiting and prioritizing by ancestor fee rate as a way to discourage people from wasting network bandwidth. This proposal aims to address the issue of publishing transactions that will never get confirmed while still ensuring incentive compatibility. They also discuss the importance of having a path that follows the new relay rules and gets support from a significant portion of hashpower.The post delves into the discussion of improving Bitcoin's Replace-by-Fee (RBF) feature in transactions. Developer Jeremy Rubin proposes several changes to address issues and potential attacks. These changes involve removing rules that require higher fees, preventing pinning attacks, and creating a more user-friendly interface for fee bumping transactions. Rubin also discusses models for transaction validation rate-limiting and enhancing the mining score of mempool transactions.The author introduces a new rule called the "feerate-based" rule, which aims to replace transactions in the mempool. This approach entails calculating conflicting transactions and their descendants, identifying original transactions for inclusion in the next block, and ensuring replacements pay at least the same amount plus a certain percentage in absolute fees. Replacements must also have a higher feerate than the maximum mining score of remaining transactions in the mempool after the next block. The proposal suggests utilizing TBD constants to limit the number of replacements allowed with specific fees.Various implementation options for the feerate-based replacement rule are discussed, including dynamic block templates, cached block templates, or dividing the mempool into different feerate layers. Throughout the document, links to relevant pull requests, issues, and discussions are provided for further context.
Updated on: 2023-08-02T05:30:18.072198+00:00