Proposal: Package Mempool Accept and Package RBF

Summary:

The proposed Package RBF policy aims to enable package validation without any consensus or P2P protocol changes. This policy allows for packages consisting of multiple parents and one child. The mempool stores the best candidates for inclusion in a block, with miners using it to build block templates. However, to mitigate DoS attacks from malicious peers, a set of validation rules are applied to unconfirmed transactions. These rules protect against resource exhaustion and maintain the highest fee transactions.The proposed changes include enabling package validation in preparation for package relay in Bitcoin Core. The package cannot exceed 25 counts and 101KvB total size, and the package cannot replace more than 100 mempool transactions. The proposal enables C to pay for A's conflicts since their package feerate is used in the fee comparisons. As long as A only conflicts with A', it won't be trying to replace more than 100 transactions. The proposed changes accommodate diagrams like A but not like diagram B, where C is getting CPFP carve-out and wants to bring a +1.The Package Relay and Package Mempool Accept in transaction relay considers transactions one at a time for submission to the mempool. To address this limitation, the end goal for Package Relay is to consider multiple transactions at the same time. This may help better determine whether transactions should be accepted to the mempool, especially if they don't meet fee requirements individually or are better RBF candidates as a package. Additionally, this proposal allows packages to contain already-in-mempool transactions and enables parents to RBF mempool transactions with a set of rules similar to BIP125. The proposed changes include allowing packages to contain transactions that are already in the mempool, only allowing packages of a specific topology, using the package feerate to meet the two feerate requirements of a mempool, and enabling parents to replace-by-fee mempool transactions. These changes aim to improve the propagation of transactions and make fee-bumping tools more powerful for users. There is a draft implementation available, but feedback is welcome.The Package RBF signaling logic should be the same for package RBF and single transaction acceptance. New unconfirmed inputs may be included in a package, but the ancestor feerate of the child must be at least as high as the ancestor feerates of every transaction being replaced. The rule analogous to BIP125#2 would be "none of the transactions in the package can spend new unconfirmed inputs." The package must increase the absolute fee of the mempool, pay for its own bandwidth, and cannot replace more than 100 mempool transactions. It is possible for only some of the package to make it into the mempool, but the most common scenario would be all-or-nothing. We shouldn't allow packages to contain already-confirmed transactions due to practical reasons. Overall, the Package RBF rules are less strict than BIP125 and ensure that the replacement transactions have a higher ancestor score than the original transactions.

Updated on: 2023-06-15T02:11:58.342014+00:00