Published on: 2021-10-14T10:48:55+00:00
The email thread on the bitcoin-dev mailing list discusses various aspects of the proposed package relay for Bitcoin Core. The discussions revolve around package acceptance rules, deduplication, and topologies. There is a debate on the logical order of the proposed checks and whether only the package RBF should apply. The limitations on topology are also discussed, with some suggesting a conservative approach of deploying during a first phase of 1-parent/1-child.Gloria Zhao and Antoine Riard discuss the proposed implementation of package relay for Bitcoin. They cover topics such as the removal of transactions already in the mempool during package submission, evaluation of fee rates for packages, and how replacements will work. They also discuss potential issues with multi-parent-1-child packages and their use in fee-bumping replaceable transactions. They mention the possibility of implementing a "witness replacement" project alongside package mempool acceptance.There is a discussion about the rules for Package Replace-by-Fee (RBF) in Bitcoin. The proposal includes conditions such as having a higher ancestor score than the original transactions, not including new unconfirmed inputs unless they were included in the original transactions, and having a total fee higher than the replaced transactions. The package feerate must be higher than the replaced transactions by at least the minimum relay feerate, and the package cannot replace more than 100 mempool transactions.The conversations aim to improve the efficiency and security of Bitcoin's mempool. There are concerns about Lightning developers who may not be aware of mempool subtleties and suggestions to constrain L2 design space using a 1-parent + 1-child model. The discussions cover various scenarios, including batched fee-bumping, mempool conflicts, and multi-commitment-broadcast-as-one-package. The goal is to make fee-bumping tools more powerful for users while maintaining transaction safety.There are proposals for changes to Bitcoin Core's mempool policy to enable package validation for package relay. The proposed policy allows for packages with multiple parents and one child to be validated together, improving fee-bumping tools for time-sensitive transactions. The proposal also introduces the concept of Package Mempool Accept, which includes changes to mempool validation logic, policy, and transaction relay to propagate transactions with the highest package feerates to miners.The discussions also touch on potential risks and safety concerns related to package acceptance and replacements. Concerns are raised about CPFP batching for Lightning Network time-sensitive closure and the possibility of malicious transactions delaying transaction propagation and confirmation within the same package. There is a focus on ensuring better utilization of block space while maintaining transaction safety.Overall, these discussions aim to enhance the transaction process in the Bitcoin network by optimizing validation, propagation, and fee-bumping tools. The proposals and debates explore various aspects of package acceptance, replacement-by-fee rules, and topology limitations. The goal is to improve efficiency, security, and flexibility for users and applications like Lightning.The Bitcoin Core development team has proposed a new system called package relay to improve transaction validation and propagation. This system allows for the creation of packages consisting of multiple parents and one child, which aids in fee estimations and transaction relay. The proposal introduces package feerate, which considers modified fees and virtual size of all transactions in the package. It also sets limitations on fee-bumping to prevent DoS vectors and ensures that replacement transactions have an ancestor score at least as high as the original ones. The package relay system has implications for Lightning Network (LN) requirements and other Layer 2 protocols/applications. It is suggested to deploy it in a phased manner to improve second-layer safety. The proposed system enables CPFP within packages and provides fee-bumping tools for users. To test the submission logic, Package Mempool Accept initially uses RPC. Fee-related checks use the package feerate, and parents can replace mempool transactions, but the child cannot. The bitcoin-dev mailing list has discussed the proposal, exploring differences from BIP125 and addressing potential scenarios and FAQs.Overall, the package relay system aims to improve package validation and relay in Bitcoin Core without requiring consensus or P2P protocol changes. It allows for better propagation of high-feerate transactions, more powerful fee-bumping tools for users, and adjustments to fees at broadcast time for Layer 2 applications. The proposed changes include modifications to mempool policy, allowing for packages with multiple parents and one child, and using the total package feerate instead of individual feerates. The author provides a draft implementation of the proposal and clarifies terminology and existing rules. However, there are limitations, such as the package not being able to replace more than 100 mempool transactions and not being able to contain already-confirmed transactions.
Updated on: 2023-08-02T04:48:13.719007+00:00