Author: Antoine Riard 2021-09-26 21:10:14
Published on: 2021-09-26T21:10:14+00:00
In a discussion between Gloria and Antoine, they agreed on most points regarding package mempool acceptance but there are still decisions that need input from other developers. These decisions include whether to start with multiple-parent-1-child or 1-parent-1-child, and whether it's okay to require that the child not have conflicts with mempool transactions. They also discussed potential pinning attacks where an attacker can exploit the system by blocking commitment transactions from different channels. They also discussed the safety of replacing witnesses, which is currently limited by first-seen witness limitations. Additionally, they talked about how to deal with dishonest packages in P2P, with Gloria suggesting that they only use package validation when unsatisfied with single validation results. Finally, they talked about whether the child should be able to replace mempool transactions, which is important for Lightning as A+B is coming from Alice and A'+B' is coming from Bob.The discussion revolves around the proposal of using packages for fee-bumping replaceable transactions. The Lightning use case being addressed is when Alice and Mallory have commitment transactions that conflict with each other, but the outputs spent by their respective counterparties don't conflict with each other. A package can replace mempool transactions if any of the parents conflict with mempool transactions, but the child cannot conflict with any mempool transactions. The proposal for a set of mempool policy changes to enable package validation and relay in Bitcoin Core has been presented. The proposal enables packages with multiple parents and one child, and the implementation draft can be found in Bitcoin Core PR#22290. The post clarifies terminology such as Package Feerate, Modified Fees, Virtual Size, Fee-Bumping, Child Pays for Parent (CPFP), and BIP125 Replace-by-Fee (RBF). The proposal aims to recognize when a new transaction is more economical to mine than the original through mempool policy. The purpose of the Bitcoin mempool is to store the best candidates for inclusion in a block. It is also useful as a cache for boosting block relay and validation performance, aiding transaction relay, and generating feerate estimations. An individual transaction that does not meet the minimum mempool feerate will not be accepted by mempools. Package Relay, part of Package Mempool Accept project, allows for multiple transactions to be considered at the same time, enabling better determination of which transactions should be accepted into the mempool. Bitcoin developers have proposed a new set of rules for package replacement-by-fee (RBF) in the Bitcoin network, with a modified version of Bitcoin Improvement Proposal 125. The proposal includes a total of five rules which must be followed by packages that want to replace existing transactions in the mempool. It states that all mempool transactions to be replaced must signal replaceability and the package may include new unconfirmed inputs, but the ancestor feerate of the child must be at least as high as the ancestor feerates of every transaction being replaced. Additionally, it requires the package to increase the absolute fee of the mempool, pay for its own bandwidth and cannot replace more than 100 mempool transactions.The proposal also addresses the issue of whether to allow packages to contain already-confirmed transactions. The proposal suggests that it is not practical to do so because the mempool validation process relies on inputs using a UTXO set, which makes it difficult to identify confirmed transactions. Furthermore, the proposal emphasizes that nobody should be relaying transactions that have already been confirmed, and similarly, packages containing already-confirmed transactions should not be relayed.The context provided is a mailing list called "bitcoin-dev" hosted on lists.linuxfoundation.org. The mailing list is dedicated to discussions related to the development of Bitcoin, a digital currency that uses encryption techniques to regulate the generation of units of currency and verify the transfer of funds. The mailing list can be subscribed to by visiting https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev. The email address for the list is bitcoin-dev@lists.linuxfoundation.org.
Updated on: 2023-06-15T02:14:02.219869+00:00