Proposal: Package Mempool Accept and Package RBF

Summary:

Gloria Zhao has proposed a set of mempool policy changes to enable package validation in Bitcoin Core. The proposal aims to better propagate transactions with the highest package feerates to miners and make fee-bumping tools more powerful for users. The end goal for Package Relay is to consider multiple transactions at the same time, e.g., a transaction with its high-fee child.A combination of changes to mempool validation logic, policy, and transaction relay allows us to better propagate the transactions with the highest package feerates to miners. The "relay" part of Package Relay suggests P2P messaging changes, but a large part of the changes are in the mempool's package validation logic. We call this Package Mempool Accept.Some previous efforts have been made to make mempool validation less opaque. These include adding basic capabilities for package validation, test accepts only, implementing package ancestor/descendant limit checks for arbitrary packages, and previous package relay proposals.Existing package rules state that a package cannot exceed `MAX_PACKAGE_COUNT=25` count and `MAX_PACKAGE_SIZE=101KvB` total size. Packages must be topologically sorted, and there cannot be conflicting transactions. When packages are evaluated against ancestor/descendant limits, they cannot replace more than 100 mempool transactions.Regarding package RBF rules, if an unrelated transaction exists in the mempool when a user submits a package that includes a transaction spending the same input as the unrelated transaction, the package may be rejected. This presents a security issue for LN and other protocols that create UTXOs with multiple spending paths.The Package Mempool Accept project proposes changes to the mempool acceptance logic for Bitcoin packages. Packages may contain transactions already in the mempool, meaning such transactions are removed during package mempool acceptance. These packages are Multi-Parent-1-Child, allowing fee-bumping by CPFP and simplifying validation logic. The package feerate is used to meet feerate requirements instead of individual feerates, allowing "CPFP within a package." Parents may RBF mempool transactions with a set of rules similar to BIP125, while the child cannot replace mempool transactions. The package cannot replace more than 100 mempool transactions.The discussion on the Bitcoin-dev mailing list revolves around two main topics related to package validation. The first topic is whether the package child should be sponsoring the fees of its parents, and if so, whether it should be all-or-nothing. The second topic is whether packages should contain already-confirmed transactions.It is agreed that this scenario is incentive-compatible and that package validation should begin by submitting all transactions individually before using the package mempool acceptance logic if parents fail due to low feerate. It is concluded that allowing such transactions is impractical because we can't tell with 100% confidence if we are looking at a transaction that has already confirmed, and transaction relay is somewhat "stateful." Numerous links are provided in the context for further reading, including discussions and proposals regarding package validation and transaction size calculations. Visual aids are also included to illustrate the concepts being discussed. Feedback is welcome on the draft implementation, which is available at [#22290][1].

Updated on: 2023-06-15T01:56:46.511843+00:00