Author: Gloria Zhao 2022-09-26 16:47:49
Published on: 2022-09-26T16:47:49+00:00
Gloria responds to feedback on her proposal for a minimally-invasive step that works for Lightning today. She clarifies that the proposal is tailored for LN Penalty and does not close all pinning attacks possible. Gloria acknowledges that some bits can be a little ugly or tack-on, but hopes to get more ideas with the "RBF Improvements" post in January. The proposal does not fix existing pinning attacks for single transaction RBF but also doesn't make them worse.Gloria adds that the strategy of using ACP to bring-your-own-fees has its own challenges but hopefully has no current use cases as LN Penalty is not affected by this since it doesn't use ACP. In response to a concern raised about HTLC/commitment-like transactions being resolved in a batch, she suggests that this is a separate, wallet-related problem and does not see how a replace-by-ancestor-feerate policy would make any difference for this.She reiterates that ancestor feerate is not a panacea to all their RBF incentive compatibility concerns and that they are estimating the incentive compatibility of the original transaction(s) and replacement transaction(s). Some suggestions were made for improvement, including detecting a "sibling output spend" conflict, allowing OP_TRUE to become a standard script type, and having a single dust-value output which is immediately spent by the package. Gloria agrees that these suggestions could be quite useful and discusses their implications.A proposal has been put forward for a set of mempool and transaction relay policies to aid Layer 2/contract protocols. The proposal includes a set of additional policy rules applying to V3 transactions, and modifications to package RBF rules. V3 transactions can be replaced, even if they do not signal BIP125 replaceability, and any descendant of an unconfirmed V3 transaction must also be V3. An unconfirmed V3 transaction cannot have more than one descendant and is limited to 1000 virtual bytes in size. Additionally, all package transactions with mempool conflicts must be V3.These changes aim to provide inherited replaceability signaling when descendants of unconfirmed transactions are created, and to prevent pinning attacks by malicious counterparties. The proposal has already been implemented and documented for Bitcoin Core.The Bitcoin development team has announced a new policy that will only allow V3 transactions to replace their ancestors' conflicts, and only V3 transactions' replacements may be paid for by a descendant. This means that only child-with-parents packages will be allowed for package validation. The fee-related rules are economically rational for ancestor packages, but not necessarily other types of packages. A child-with-parents package is a type of ancestor package and it may be fine to allow any ancestor package, but it's more difficult to account for all of the possibilities. Intended usage for LN involves commitment transactions that should be V3 and have 1 anchor output. They can be signed with 0 fees (or 1sat/vbyte) once package relay is deployed on a significant portion of the network. If the commitment tx must be broadcast, determine the desired feerate at broadcast time and spend the anchor output in a high feerate transaction.The child must be V3 and at most 1000vB. One child may fund fees for multiple commitment tx ("batched fee-bumping"). To do a second fee-bump to add more fees, replace the child with a higher-feerate tx. Otherwise, never try to spend from an unconfirmed V3 transaction. The descendant limits for V3 transactions are very restrictive. The V3 descendant limit restricts both you and your counterparty. Assuming nodes adopted this policy, you may reasonably assume that you only need to replace the commitment transaction + up to 1000vB.The Bitcoin development team has answered some expected questions about this policy. For example, if this fix Rule 3 Pinning? Yes, the V3 descendant limit restricts both you and your counterparty. Assuming nodes adopted this policy, you may reasonably assume that you only need to replace the commitment transaction + up to 1000vB. Moreover, is this a privacy issue, i.e. doesn't it allow fingerprinting LN transactions based on nVersion? Indeed, it may be unrealistic to assume V3 transactions will be in widespread use outside of L2.Lastly, the development team has clarified that a V3 transaction that does not signal BIP125 replaceability is replaceable. It's not an issue because, under previous policy, the V3 transaction wouldn't have been in the mempool in the first place. A V2 transaction can replace a V3 transaction and vice versa, otherwise someone can use V3 transactions to censor V2 transactions spending shared inputs. Thanks for reading! Feedback and review would be much appreciated.
Updated on: 2023-06-16T00:35:35.692164+00:00