Author: Greg Sanders 2022-09-29 14:41:28
Published on: 2022-09-29T14:41:28+00:00
Bitcoin developer Gloria Zhao has proposed a new version of transaction format, V3, aimed at improving replace-by-fee (RBF) and child-pays-for-parent (CPFP) protocols. The proposal includes four rules that specify limits on the size and number of "descendant" transactions, or those that rely on an unconfirmed parent transaction for funding. One of the key changes is that a V3 transaction cannot change based on what transactions are mined, which simplifies subsequent rules about descendant limits much easier to check. Unconfirmed V3 transactions cannot have more than one descendant. A V3 transaction that has an unconfirmed V3 ancestor cannot be larger than 1000 virtual bytes. Commitment transactions should also be V3 and have one anchor output.The proposal aims to prevent pinning attacks where a malicious counterparty prevents a transaction from being replaced by adding many descendant transactions that aren't fee-bumping. The smaller the descendant size limit, the fewer UTXOs a child may use to fund this fee-bump. However, as the fee-bumping child only needs to fund fees, just a few UTXOs should suffice. With a limit of 1000 virtual bytes, depending on the output types, the child can have 6-15 UTXOs, which should be enough to fund a fee-bump without requiring a carefully-managed UTXO pool.Package RBF modifications have also been suggested. One of the main changes is that all package transactions with mempool conflicts are required to be V3. This also means the "sponsoring" child transaction must be V3. The proposals are intended for usage in Layer 2 Bitcoin transactions, such as commitment transactions on the Lightning Network. A proposal for a minimally-invasive step to enable fee-bumping presigned transactions specifically using Child-Pays-For-Parent (CPFP) and anchor outputs has been put forward. The proposal intends to fix the Lightning Network Penalty and does not close all pinning attacks possible. While it is tailored for LN Penalty, it works for Lightning today. One scenario it does not fix is where HTLC/commitment-like transactions are being resolved in a batch, but due to relative time constraints, you may want to accelerate some and not others. This RBF package would require replacements to be better mining candidates.It is suggested that the current package RBF logic may cover this scenario as they are simply replacing [ParentTx, ChildTx1] with [ParentTx, ChildTx2] that pays more fees. The proposal has received feedback from various individuals who have shared their thoughts and suggestions. Improvements to restrict the whole v3 package's size via committing to a specific value in the taproot annex were suggested. However, it was believed that this could make relay policy stricter, and therefore this change can be done in a second, separate step. Making OP_TRUE standard and allowing outputs that are below dust was also suggested, but it was agreed that it can be added later.Some other ideas were discussed, such as detecting a "sibling output spend" conflict and knocking it out of the mempool via other replacement rules. This will eliminate the requirement to 1 block CSV lock every output and would be quite nice from a smart contracting composability point of view. The proposal also addresses issues surrounding fingerprinting of LN transactions on the spec-defined amount value of the anchor outputs. It was agreed that this is not worse than today, and unilateral closes will probably always be identifiable on-chain.On the Bitcoin-dev mailing list, Bastien Teinturier praised Gloria Zhao's work on package RBF, which is intended to aid L2/contract protocols and improve their security models. He suggested making a single anchor output spendable by both participants and adding a neat feature that would detect a "sibling output spend" conflict. Both suggestions were welcomed. The email also discussed a few additional rules applying to V3 transactions, such as allowing them to be replaced even if they don't signal BIP125 replaceability and requiring all descendants of an unconfirmed V3 transaction to be V3.Overall, the proposal has generated positive feedback, and it is believed that it would be valuable to add this feature. New logic is required to handle some cases, but it is doable and worth adding. The use of ephemeral anchors + v3 solves some of the issues already, and it's great news if we can directly source fees from any output claimable, including HTLCs. Feedback and review of the proposal are welcome.
Updated on: 2023-06-16T00:27:46.654786+00:00