New transaction policies (nVersion=3) for contracting protocols

Summary:

In a proposal to aid L2/contract protocols, Gloria Zhao suggests a set of mempool/transaction relay policies. The proposal aims to solve Rule 3 pinning and potentially eliminate CPFP carve-out. It includes additional rules for V3 transactions and modifications to package RBF rules.For V3 transactions, which are currently non-standard in Bitcoin Core, the following rules apply:1. A V3 transaction can be replaced, even without signaling BIP125 replaceability, as long as it meets other RBF rules.2. Any descendant of an unconfirmed V3 transaction must also be V3. This allows for "inherited" replaceability signaling and simplifies checking descendant limits.3. An unconfirmed V3 transaction cannot have more than 1 descendant. This prevents a pinning attack where a malicious counterparty adds many non-fee-bumping descendants.4. A V3 transaction with an unconfirmed V3 ancestor cannot exceed 1000 virtual bytes in size. This sets an upper bound on the size of fee-bumping descendants and ensures that a child transaction only needs a few UTXOs to fund the fee bump.These rules aim to provide flexibility for L2 protocols while maintaining security and efficiency. They allow for easier fee-bumping and reduce the need for managing a large UTXO pool.The proposal also includes modifications to package RBF rules. One key change is that a package may include new unconfirmed inputs, but the ancestor feerate of the child must be at least as high as the ancestor feerate of all existing inputs in the package. This ensures that a fee-bumping child transaction does not lower the overall feerate of the package.Gloria Zhao has implemented these policies in Bitcoin Core and welcomes feedback from the community. The proposal offers potential benefits for L2/contract protocols and addresses some limitations of previous proposals. It provides a solution for Rule 3 pinning and could potentially eliminate the need for CPFP carve-out.The Bitcoin development team has proposed a new package relay policy to replace BIP125, the current Replace-by-Fee (RBF) policy. The new policy includes two main changes. Firstly, the minimum between the package feerate and ancestor feerate of the child must not be lower than the individual feerates of all directly conflicting transactions and the ancestor feerates of all original transactions. This change ensures that replacement transactions are not less incentive-compatible to mine. Secondly, all package transactions with mempool conflicts must be Version 3 (V3), including the "sponsoring" child transaction.The intended usage for Lightning Network (LN) commitment transactions is also discussed. Commitment transactions should be V3 and have one anchor output. They can be signed with zero fees or a low feerate once package relay is deployed on a significant portion of the network. If the commitment transaction needs to be broadcasted, the desired feerate at broadcast time should be determined and the anchor output should be spent in a high feerate transaction. This transaction is referred to as "the parent," and a fee-bumping transaction attached to it is referred to as "the child." The child must also be V3 and can be at most 1000vB in size. Multiple commitment transactions can be funded by one child, and to add more fees, the child should be replaced with a higher-feerate transaction instead of attaching a grandchild.The new policy also addresses questions related to Rule 3 Pinning, counterparty's commitment transaction in the mempool, privacy concerns, backward compatibility, and replacing transactions between V2 and V3.

Updated on: 2023-07-14T02:32:55.677744+00:00