Author: Gloria Zhao 2021-09-20 15:10:14
Published on: 2021-09-20T15:10:14+00:00
Gloria and Antoine are discussing the proposal for package mempool acceptance in Bitcoin Core. The proposal suggests a set of mempool policy changes to enable package validation in Bitcoin Core. This change would allow packages consisting of multiple parents and one child, which could better determine whether transactions should be accepted to the mempool. The purpose of the mempool is to store the best candidates for inclusion in a block, and the mempool policy is a set of configurable rules that transactions must abide by to be accepted into the mempool.The proposal aims to address the limitation in transaction relay where transactions are considered one at a time for submission to the mempool, creating a security issue for applications and users relying on time-sensitive transactions. For example, Lightning and other protocols create UTXOs with multiple spending paths, where one counterparty's spending path opens up after a timelock, and users are protected from cheating scenarios as long as they redeem on-chain in time. They discuss various aspects of the proposal including deduplication of transactions already in the mempool, topology assumptions, and RBF rules. Gloria clarifies that if B+C is too low to be accepted, the package will be rejected and explains the reasoning behind it. She also agrees with Antoine's suggestion to handle variations of the same package with different witnesses. They also discuss the possibility of deploying during a first phase of 1-parent/1-child and later moving to multi-parent-1-child. Additionally, they discuss how the individual RBF should be bypassed and only the package RBF should apply. Finally, they touch upon the issue brought by trimming during the dedup phase and whether the dedup should be done on wtxid or txid.The proposal includes examples to illustrate different situations and possible outcomes. The proposal suggests that the current implementation of the proposal can be found in Bitcoin Core PR#22290. Additionally, it recommends improvements to inherited signaling or moving towards full-RBF and mentions other L2 protocols/applications that could use package accept/relay.Bitcoin Core developers have revealed a package relay project that aims to increase the number of transactions that can be sent across its network. The project will combine changes to mempool validation logic, policy and transaction relay to better propagate the transactions with the highest package feerates to miners. This is intended to make fee-bumping tools more powerful for users. While the "relay" part of Package Relay suggests P2P messaging changes, a large portion of the changes are in the mempool's package validation logic. Bitcoin Core developers have implemented submission to mempool, initially through RPC only, as the next step in the Package Mempool Accept project. The proposed changes include several key points. Packages may contain already-in-mempool transactions and are 2 generations, Multi-Parent-1-Child. Fee-related checks use the package feerate, allowing wallets to create a package that utilizes CPFP (Child Pays For Parent). Parents are allowed to RBF (Replace By Fee) mempool transactions with a set of rules similar to BIP125. This enables a combination of CPFP and RBF, where a transaction's descendant fees pay for replacing mempool conflicts. The draft implementation is housed on Github.There are several existing package rules, such as the fact that a package cannot exceed MAX_PACKAGE_COUNT=25 count and MAX_PACKAGE_SIZE=101KvB total size. Additionally, packages must be topologically sorted so that if any dependencies exist between transactions, parents must appear somewhere before children. A package cannot have conflicting transactions, i.e., none of them can spend the same inputs. When packages are evaluated against ancestor/descendant limits in a test accept, the union of all of their descendants and ancestors is considered. There are limitations such as the fact that CPFP carve out is not applied to package transactions and #20833 disables RBF in package validation; this proposal overrides that to allow packages to use RBF.The Bitcoin development mailing list recently discussed a proposal for an update to the Replace-by-Fee (RBF) protocol. The proposal suggests five new rules that would govern RBF, including a new rule that requires the entire package to be a higher feerate mining candidate than each of the replaced transactions. Another new rule requires the total fees of the package to be higher than the absolute fees of the mempool transactions it replaces. The proposal also includes a new rule that states the package cannot replace more than 100 mempool transactions. The discussion also addressed whether packages should be allowed to contain already-confirmed transactions, with the consensus being that this should not be allowed due to practical reasons. Several links to related Github pull requests and BIPs were included for further reference.
Updated on: 2023-06-15T01:55:29.269778+00:00