New transaction policies (nVersion=3) for contracting protocols

Summary:

The proposal for package replace-by-fee (RBF) in Bitcoin transactions aims to improve the security model for layer-two (L2) contracts. It involves using version 3 (V3) transactions that allow for replaceability through child-pays-for-parent (CPFP), which means that only the commitment transaction and up to 1000 virtual bytes (vB) need to be replaced, rather than the entire channel state. Under this proposal, any descendant of an unconfirmed V3 transaction must also be V3, and an unconfirmed V3 transaction cannot have more than one descendant. The maximum size of a V3 transaction with an unconfirmed V3 ancestor is 1000 virtual bytes.The proposal includes other changes, such as allowing a single dust-value output that is immediately spent by the package, making anchors easier to design. Batched fee-bumping of time-sensitive confirmations of commitment transactions is unsafe as it could delay confirmation of remaining elements in the batch. A recommendation is made for L2 wallets to fan-out their big UTXOs in N fan-out outputs ready to feed the remaining in-flight channels. Additionally, a suggestion is made to allow OP_TRUE to become a standard script type, saving bytes by having the input empty of witness data and making it spendable by both participants.There are also discussions on other changes that could be made to improve the RBF system, such as making OP_TRUE standard and allowing outputs below dust, and restricting the size of the whole unconfirmed package, including potential v2 unconfirmed ancestors. However, it is agreed that these changes can be added later as they won't be standard until they are allowed.Gloria Zhao has proposed a set of mempool/transaction relay policies to aid L2/contract protocols, which includes additional policy rules applying to V3 transactions and modifications to package RBF rules. The proposal aims to solve problems with the previous Package Mempool Accept package RBF and Rule 3 pinning. Commitment transactions should be V3 and have one anchor output, and the child must be at most 1000vB. By making these changes, descendant limits for V3 transactions will become more restrictive. Gloria has also provided an implementation along with documentation on GitHub. Existing standardness rules apply to V3 transactions, and they can replace even if they do not signal BIP125 replaceability. Any descendant of an unconfirmed V3 transaction must also be V3.There are concerns about the impact on the UTXO set, and the chance of the 0 sat output entering the UTXO set. It is suggested that this should not happen often in practice, but the chance is not zero. There are also discussions on limitations of the proposal, such as not fixing ANYONECANPAY situations or scenarios where HTLC/commitment-like transactions are being resolved in a batch. These issues may need a comprehensive RBF revamp in the future.Lastly, the author clarifies that V2 and V3 transactions can replace each other to prevent censorship of shared inputs. Links to the original proposal and related discussions are provided, and feedback and review are welcomed.

Updated on: 2023-06-16T00:28:55.772906+00:00