New transaction policies (nVersion=3) for contracting protocols [combined summary]

• New transaction policies (nVersion=3) for contracting protocols Greg Sanders 2023-06-21 20:57:45+00:00
• New transaction policies (nVersion=3) for contracting protocols Ruben Somsen 2022-10-01 09:59:55+00:00
• New transaction policies (nVersion=3) for contracting protocols Greg Sanders 2022-09-30 12:17:38+00:00
• New transaction policies (nVersion=3) for contracting protocols Bastien TEINTURIER 2022-09-30 12:08:41+00:00
• New transaction policies (nVersion=3) for contracting protocols Ruben Somsen 2022-09-30 00:13:53+00:00
• New transaction policies (nVersion=3) for contracting protocols Greg Sanders 2022-09-29 14:41:28+00:00
• New transaction policies (nVersion=3) for contracting protocols Bastien TEINTURIER 2022-09-29 09:15:02+00:00
• New transaction policies (nVersion=3) for contracting protocols Gloria Zhao 2022-09-26 16:47:49+00:00
• New transaction policies (nVersion=3) for contracting protocols Greg Sanders 2022-09-26 16:01:54+00:00
• New transaction policies (nVersion=3) for contracting protocols Bastien TEINTURIER 2022-09-26 15:27:40+00:00
• New transaction policies (nVersion=3) for contracting protocols Antoine Riard 2022-09-25 23:59:22+00:00
• New transaction policies (nVersion=3) for contracting protocols Greg Sanders 2022-09-23 18:48:39+00:00
• New transaction policies (nVersion=3) for contracting protocols Gloria Zhao 2022-09-23 15:18:21+00:00

Published on: 2023-06-21T20:57:45+00:00

Summary:

Bitcoin developer Gloria Zhao has proposed a new transaction format called V3, which aims to improve replace-by-fee (RBF) and child-pays-for-parent (CPFP) protocols. The proposal includes rules that limit the size and number of descendant transactions, allowing for easier fee-bumping and reducing the need for managing a large UTXO pool. These rules provide flexibility for Layer 2 (L2) protocols while maintaining security and efficiency.Under the proposed rules, a V3 transaction can be replaced even without signaling BIP125 replaceability, as long as it meets other RBF rules. Any descendant of an unconfirmed V3 transaction must also be V3, and an unconfirmed V3 transaction cannot have more than one descendant. Additionally, a V3 transaction with an unconfirmed V3 ancestor cannot exceed 1000 virtual bytes in size.The proposal also discusses the intended usage for Lightning Network (LN) commitment transactions, which should be V3 and have one anchor output. 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. Multiple commitment transactions can be funded by one child, and to add more fees, the child should be replaced with a higher-feerate transaction.In addition to the V3 transaction format, 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 changes to the feerate requirements and ensures that replacement transactions are not less incentive-compatible to mine. It 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.The proposed policies aim to improve RBF and CPFP protocols, with specific rules for V3 transactions and modifications to package RBF rules. The changes aim to provide inherited replaceability signaling and prevent pinning attacks. 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. Feedback and review of the proposal are encouraged by the development team.

Updated on: 2023-08-02T07:37:32.592526+00:00