Author: Gloria Zhao 2021-09-23 15:36:02
Published on: 2021-09-23T15:36:02+00:00
Gloria and Antoine discuss a proposed package mempool acceptance logic for Bitcoin transactions in an email conversation. They agree on certain aspects but also seek input from developers on decisions such as whether to start with multiple-parent-1-child or 1-parent-1-child and whether the child can have conflicts with mempool transactions. They also discuss batched fee-bumping, safety, and the Lightning use case. Gloria proposes solutions for RBF and explains how it addresses the Lightning use case. Antoine raises concerns about batched fee-bumping and potential risks of unsafe usage of the package API by L2 developers.Antoine reviews and discusses various aspects of the proposed package mempool acceptance rules for Bitcoin with Gloria. They consider issues related to performance, broadcasted packages being honest, handling of in-package transactions already in the mempool, and prioritizing transactions using ancestor score vs absolute fees. They also consider different topologies for parent-child transactions and potential safety risks for Lightning Network time-sensitive closures. Gloria proposes solutions such as deduplication by wtxid, using package feerate after dedup, and allowing multi-parent-1-child transactions. They also address concerns about individual RBF and propose using package RBF instead, and discuss the implications of ignoring both fees and vsize when calculating package feerate for transactions already in the mempool.The discussion revolves around refining the proposed package mempool acceptance rule to ensure it is safe and effective. The proposed rule involves creating transaction packages that can contain transactions already in the mempool, with these transactions removed during deduplication. However, if the highest-fee transaction in a package is already in the mempool, the package may fail the BIP125#4 rule. There are concerns regarding package topology, including the safety of child transactions replacing mempool transactions and whether the current proposal breaks the naive broadcaster assumption of higher-feerate/higher-fee packages always replacing lower ones. There are also questions about the rules around malleability of child transactions and preserving package integrity during the deduplication phase.The proposed changes include allowing packages to contain already-in-mempool transactions, multi-parent-1-child topology, and using the package feerate for fee-related checks. Parents are allowed to RBF mempool transactions with a set of rules similar to BIP125, enabling a combination of CPFP and RBF. The end goal of Package Relay is to consider multiple transactions at the same time and make fee-bumping tools more powerful for users. Feedback is welcome, and there is a draft implementation in PR#22290.Bitcoin Core developers propose "package RBF" as a new method to replace-by-fee transactions. This process allows RBF of entire transaction packages, making it easier to validate and simplifying the logic greatly. Package feerate is used instead of individual feerate, allowing L2 applications to adjust their fees at broadcast time. The child in the transaction package can replace mempool transactions but only if the ancestor feerate of the child is at least as high as the ancestor feerates of every transaction being replaced. The package must increase the absolute fee of the mempool and cannot replace more than 100 mempool transactions. Packages that contain already-confirmed transactions cannot be relayed.The context provided includes links to images depicting various aspects of Bitcoin, such as transaction fees and mempool size, and a mailing list hosted on the Linux Foundation website for Bitcoin developers to discuss issues related to cryptocurrency development. However, the context does not provide any additional information or details about specific topics being discussed on the mailing list.
Updated on: 2023-06-15T02:01:35.028628+00:00