Author: Antoine Riard 2021-09-28 22:59:11
Published on: 2021-09-28T22:59:11+00:00
The email thread on the bitcoin-dev mailing list discusses various aspects of the proposed package relay for Bitcoin Core, including package acceptance rules, deduplication, and topologies. The group debates the logical order of the checks proposed 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 1-parent/1-child. The group also talks about the issue of requiring replacement transactions to have an ancestor score at least as high as the original ones. Finally, they discuss the potential safety concerns for L2s if counterparties have malleability of the child transaction and suggest fixing inherited signaling or moving towards full RBF.The conversation is regarding the proposed package replace-by-fee (RBF) logic for Bitcoin transactions. The discussion covers various scenarios such as batched fee-bumping, mempool conflicts, and Lightning multi-commitment-broadcast-as-one-package. One important point made is that it's impossible to assume that p2p packages will be honest, and they may require additional validation. The proposed package RBF rule utilizes the fees and size of the entire package, and this can be pretty high if there are potential conflicts with other commitment transactions. The discussion also covers the use of multi-parent-1-child transactions, which may artificially constrain Lightning's design space but minimize the risk of unsafe usage of the package API. Overall, the proposed package RBF logic aims to ensure better utilization of block space while maintaining transaction safety.The author of a proposal for mempool policy changes in Bitcoin Core is seeking feedback on enabling package validation in preparation for package relay. The proposed policy would allow for packages consisting of multiple parents and one child to be validated together, enabling more effective fee-bumping tools for users relying on 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 better propagate transactions with the highest package feerates to miners. The proposal includes a draft implementation in Bitcoin Core PR#22290.The conversation pertains to the proposal of a new package mempool acceptance logic that allows for fee bumping via packages. The proposal suggests ignoring both the fees and vsize of a transaction already submitted to the mempool when calculating package feerate in order to correctly calculate RBF penalty replacement. There is also discussion around deduplication being done on wtxid rather than witness, the limitations on connectivity, and the enforcement of MAX_PACKAGE_COUNT=25. Concerns are raised about the safety of CPFP batching for LN time-sensitive closure and the potential for malicious transactions to delay the propagation and confirmation of transactions within the same package.The Bitcoin team has proposed a new update to improve the transaction process. The update includes packaging transactions into one big transaction. These packages have multi-parent and one-child topology. Packages can 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. The package must increase the absolute fee of the mempool, and the package feerate must be higher than the replaced transactions by at least minimum relay feerate. The proposal uses a set of rules slightly modified from BIP125. It is also not possible for packages to contain already-confirmed transactions.Recently, the Bitcoin Core team has proposed changes to the default transaction relay policy in order to improve the privacy of Bitcoin users. The proposed changes are based on BIP-125, which outlines a new transaction relay protocol that improves privacy by randomizing the order in which transactions are relayed. Additionally, the changes aim to reduce the impact of spam attacks on the network by introducing limits on the number of low-fee transactions that can be included in a block. These changes are currently under review and may be subject to further modifications before being implemented.
Updated on: 2023-06-15T02:03:33.906061+00:00