Author: Ruben Somsen 2022-09-30 00:13:53
Published on: 2022-09-30T00:13:53+00:00
The bitcoin-dev mailing list has proposed a new set of mempool/transaction relay policies to aid L2/contract protocols. The proposal aims to improve the security model of L2 contracts and enhance the composability of smart contracting. It includes a package RBF logic, which will replace the parent transaction with a child that's high-fee, making the original tx stuck in the mempool. The proposal also suggests using fingerprinting and an anchor output to detect unilateral closures and allow fee-bumping without publishing one's commitment.Moreover, the proposal recommends a few modifications to the existing policy rules, such as increasing the upper bound of the V3 transaction size to accommodate large UTXOs, allowing OP_TRUE as a standard script type, and adding a 0-value output to make anchors easier to design. However, some concerns have been raised about compatibility with miner incentives and potential utxo set bloat issues.A proposal has been put forward to use package RBF/relay to bump presigned transactions, which should solve Rule 3 pinning and may allow the removal of CPFP carve-out. Transactions with nVersion=3 ("V3 transactions") are currently non-standard in Bitcoin Core, but this proposal includes a set of additional policy rules applying to V3 transactions and modifications to package RBF rules. Existing standardness rules apply to V3, but additional rules include that a V3 transaction can be replaced even if it does not signal BIP125 replaceability, any descendant of an unconfirmed V3 transaction must also be V3, an unconfirmed V3 transaction cannot have more than one descendant, and a V3 transaction that has an unconfirmed V3 ancestor cannot be larger than 1000 virtual bytes.Commitment transactions should be V3 and have one anchor output. The child must be at most 1000vB, restricting the number of inputs that can be used to fund the fee bump, and only one child may fund fees for multiple commitment tx ("batched fee-bumping"). Feedback and review on the proposal is welcome.In a Bitcoin-dev thread, Ruben suggested making OP_TRUE standard and allowing outputs below dust as it could solve a big cost issue in his spacechains design if transactions could have 0 fees and use a 0 sat output to pay all the fees with CPFP. He proposed that a tx containing a single 0 sat OP_TRUE output should get relayed only if it is a package where the OP_TRUE output is currently being spent in a way that increases the overall fee rate. However, there is still one theoretical edge case where another CPFP tx can feebump the package on a different output with an even higher fee rate, causing the 0 sat output to enter the UTXO set.Greg Sanders pointed out that this change would require new logic to handle the situation and added that ephemeral anchors + v3 solves this already. Gloria Zhao agreed with most of the discussion around limitations being ideas for future improvements rather than criticisms of the proposal. She proposed that restricting the whole v3 package's size via committing to a specific value in the taproot annex would be valuable and could be done in a separate step since this would make relay policy stricter. Bastien TEINTURIER agreed and added that getting rid of the requirement to 1 block csv lock every output would be nice from a smart contracting composability point of view.Furthermore, they discussed how the package RBF does not fix ANYONECANPAY situations or HTLC/commitment-like transactions being resolved in a batch due to relative time constraints. They also acknowledged that ancestor feerate is not a panacea to all RBF incentive compatibility issues since unless the mining algorithm runs, it cannot tell exactly how quickly a transaction would be mined. Additionally, they discussed how the 1000 vb upper bound constraint on V3 transactions having an unconfirmed V3 ancestor rationalizes pinning counterparty to attach high fees to a child to increase its odds of confirming.
Updated on: 2023-06-16T00:34:03.730303+00:00