Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 18E50C002D for ; Thu, 29 Sep 2022 14:41:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id CCE3841B3B for ; Thu, 29 Sep 2022 14:41:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CCE3841B3B Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=pAZOR6f3 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 794-NMUc_wgh for ; Thu, 29 Sep 2022 14:41:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6EB1E41B3A Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by smtp4.osuosl.org (Postfix) with ESMTPS id 6EB1E41B3A for ; Thu, 29 Sep 2022 14:41:40 +0000 (UTC) Received: by mail-pg1-x52f.google.com with SMTP id s26so1632431pgv.7 for ; Thu, 29 Sep 2022 07:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=3i1sHLewdSpmS3K6yBHZayQZLdJsuRNtXZ0YG2VLVIM=; b=pAZOR6f3M5MWT24i+nurQITuCjdJliqaMk94zmE2jF4UvA4nFXwG6IumqSP2wGzJW5 04JgvwfqnSW+/kjWt4p94Wfb96lM8BMc6I3B2ltBHnZzFVWCnWKZOXQ54QIfTeHSs8UM Ehv7BdHEL4Yab0UnUdEhnN7yHjahB5L8srGCLmWpSJE89SZBlxUxBj0RhbPpuVyxRLPH WTLO2WAuRaNTjqBsuC2wMljFXqqOIcvOPYuxWLbJbSYyBWni0pVNsTzrMLJ09eu0m2RL PmULmmISuNp1akUPGMEhTbAkZ+zOMG/nHUs1lUzVNVv8SaA6yOWm0WYjYBuuIP4pbVWI mR5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=3i1sHLewdSpmS3K6yBHZayQZLdJsuRNtXZ0YG2VLVIM=; b=jbIMJzfvIER3cuMBHpcy0GStGJHXKwlqFmcFqlN994bzFxjtj6ExOU/v+if7DOdkdC hyrirqsvjbcy97taMBQj0bvSQ1YOKo2iviS0bfhmVP6hcSYFBrRc2tUZro0mY8UmRXJ2 s/cZRwxWys+FjsqptVMO3JdhfECqkHSH3NXj6guzJT6pXbFXKvoFuOuCLsgArKz/jKQJ 2uz0VHpfvdmqlsP4Z4c4WLgT2pfBqcxCxfNPiIe2wiC3vqJyDm6Bm/akIEfRutvictp+ s41boTXMLbIZy60lzUNjVmCgTii+J/gKJTfP+wM6hJPtxfTNeuLjtJnceCb4oA1uuB/j k/dQ== X-Gm-Message-State: ACrzQf2Vxf+2R9dho5zSvwILo+95SzQWy6YF2Yt1KFh07yuj2Fe7EJNQ 6IWt70RdT1tbNfCw/NZJcwjyeo10fCNIiUy6Xd8= X-Google-Smtp-Source: AMsMyM5KG5Ljko6SY0kordcEp4EIy9+CXDDDQc1cd+6lvC3IKm+F5oG6lEt3Tbk3qFGc0QBP9++zRw/qHjl7z7mlI5I= X-Received: by 2002:a63:4f09:0:b0:440:4706:2299 with SMTP id d9-20020a634f09000000b0044047062299mr2664570pgb.115.1664462499567; Thu, 29 Sep 2022 07:41:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Thu, 29 Sep 2022 10:41:28 -0400 Message-ID: To: Bastien TEINTURIER Content-Type: multipart/alternative; boundary="000000000000075e2705e9d1e0c9" X-Mailman-Approved-At: Thu, 29 Sep 2022 14:50:28 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2022 14:41:45 -0000 --000000000000075e2705e9d1e0c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Right, good catch, this does require new logic to handle this case. As Gloria points out, this should be doable, and is definitely worth adding (those CSV 1 on every other output are really hacky, glad to find a way to get rid of them). For the record, it turns out ephemeral anchors + v3 solves this already, as the anchor must be spent, and the parent tx may only have one child. Somehow I missed this implication for a few months. It's great news if we can directly source fees from any output claimable, including HTLCs! On Thu, Sep 29, 2022 at 5:15 AM Bastien TEINTURIER wrote= : > Hi Gloria, Greg, > > > I interpret most of the discussion around limitations as ideas for > > future improvements rather than criticisms of the proposal > > As far as I'm concerned, definitely! > > My current understanding is that the main change/improvement that would > make sense here is restricting the whole v3 package's size (instead of > just the child) via committing to a specific value in the taproot annex > (also note that it's probably not just the v3 package's size, it should > be the whole unconfirmed package including potential v2 unconfirmed > ancestors). > > While I think this would be very valuable and would like to see this > happen, I believe that can be done in a second, separate step since this > would make relay policy stricter (some v3 transactions that previously > propagated wouldn't propagate under this new rule). As long as you are > able to find a path to miners through upgraded peers that use this annex > approach, you should be able to resolve ACP pinning issues? > > I'm curious to know how other people feel about that: is it ok to do > later or should we try to implement this for the first release of v3 > transactions? > > The other change mentioned (making OP_TRUE standard and allowing outputs > that are below dust) can be added later, as those won't be standard until > we start allowing them, so there shouldn't be any backwards-compatibility > issue with postponing this change. But maybe it's still worth having from > the get-go, even though it may take a bit more time? Again, I'm curious t= o > have other people's opinion here, I'd be happy to get all of those direct= ly > in the first release of v3 transactions, but I don't know how much > implementation will have to go into that. > > > For clarification, package RBF is ParentTx*s*(plural), and > ChildTx(singular), > > so it might be a bit more complicated than we're thinking > > Right, good catch, this does require new logic to handle this case. > As Gloria points out, this should be doable, and is definitely worth > adding (those CSV 1 on every other output are really hacky, glad to > find a way to get rid of them). > > Thanks, > Bastien > > Le lun. 26 sept. 2022 =C3=A0 18:48, Gloria Zhao a > =C3=A9crit : > >> Hi Greg, Antoine, Bastien, >> >> Thanks very much for the feedback! I interpret most of the discussion >> around limitations as ideas for future improvements rather than criticis= ms >> of the proposal (please correct me if I'm wrong). I'll try to respond to= as >> much as possible. >> >> Also I realize that I didn't contextualize this proposal clearly enough; >> it is very tailored for LN Penalty and definitely doesn't close all pinn= ing >> attacks possible (sorry for confusing anyone). I also agree that some bi= ts >> can be a little ugly or tack-on; I would definitely prefer a comprehensi= ve >> RBF revamp to fix all our problems and enable other fee-bumping strategi= es >> such as >> sign-ANYONECANPAY-then-bring-your-own-fees-by-adding-inputs-at-broadcast= . I >> was hoping to get some ideas with the "RBF Improvements" post in January= , >> but it doesn't seem like we're much closer to a workable proposal. I thi= nk >> this is a minimally-invasive step that works for Lightning today, a smal= l >> fix similar to CPFP carve out. >> >> > As you likely know from previous discussions the biggest scenario this >> does not fix in my estimation is ANYONECANPAY situations. If the parent >> transaction can be "inflated" by tacking on additional inputs, this mean= s >> the total weight of the parent tx lowers the effective feerate of the >> package. >> >> (For more context to other readers I wrote an explanation for this in >> "SIGHASH_ANYONECANPAY Pinning" section of RBF ML post). Yes, this >> unfortunately doesn't fix any of the existing pinning attacks for single >> transaction RBF but also doesn't make them worse. This boils down to add= ing >> an incentive compatibility rule that ensures you can't replace a >> transaction with something that will confirm slower. Package RBF has an >> ancestor feerate-based rule for this (note it is quite conservative and = not >> perfect). >> >> So in the scenario above with the "inflated" parent that was signed ACP, >> the replacement would be rejected because the package ancestor feerate i= s >> lower than the feerate of what is being replaced. But it is imperfect >> (explained below) and thus I wouldn't recommend it for single transactio= n >> replacement. So that attack still exists for single transactions, yes. >> >> The strategy of using ACP to bring-your-own-fees has its own challenges >> but hopefully has no current use cases as you say. AFAIK LN Penalty is n= ot >> affected by this since it doesn't use ACP, though obviously I agree we >> should fix it for the future. >> >> So when I said "this is intended for fee-bumping presigned txns in >> contracting protocols," I should have said "this is intended for >> fee-bumping presigned txns specifically using CPFP and anchor outputs." >> Apologies for forgetting to contextualize, I've been sitting on this for >> too long. >> >> > The other scenario it doesn't really 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. Now you mus= t >> pay higher rates to replace all of the transaction bumps. This is a >> "self-pin" and "get good at utxos noob" type problem, but it's something >> that axing rule#3 in favor of a Replace-by-ancestor-feerate system would >> get us. >> >> I understand you to mean "if you don't have enough UTXOs and you're >> forced to batch-bump, you over-pay because you need to bring them all to >> the highest target feerate." Isn't this kind of separate, wallet-related >> problem? Contracting or not, surely every wallet needs to have enough UT= XOs >> to not batch transactions that shouldn't be batched... I don't see how a >> replace-by-ancestor-feerate policy would make any difference for this? >> >> Also in general I'd like to reiterate that ancestor feerate is not a >> panacea to all our RBF incentive compatibility concerns. Like individual >> feerate, unless we run the mining algorithm, it cannot tell us exactly h= ow >> quickly this transaction would be mined. >> >> We're estimating the incentive compatibility of the original >> transaction(s) and replacement transaction(s), with the goal of not lett= ing >> a transaction replace something that would have been more incentive >> compatible to mine. As such, we don't want to overestimate how good the >> replacement is, and we don't want to underestimate how good the original >> transactions are. This rule "The minimum between package feerate and >> ancestor feerate of the child is not lower than the individual feerates = of >> all directly conflicting transactions and the ancestor feerates of all >> original transactions" is a conservative estimate. >> >> > Would kind of be nice if package RBF would detect a "sibling output >> spend" conflict, and knock it out of the mempool via the other replaceme= nt >> rules? Getting rid of the requirement to 1 block csv lock every output >> would be quite nice from a smart contracting composability point of view= . >> >> Interesting, so when a transaction hits a mempool tx's descendant limit, >> we consider evicting one of its descendants in favor of this transaction= , >> based on the RBF rules. >> Cool idea! After chewing on this for a bit, I think this *also* just >> boils down to the fact that RBF should require replacements to be better >> mining candidates. As in, if we added this policy and it can make us evi= ct >> the sibling and accept a transaction with a bunch of low-feerate ancesto= r >> junk, it would be a new pinning vector. >> >> > If you're a miner and you receive a non-V3, second descendant of an >> unconfirmed V3 transaction, if the offered fee is in the top mempool >> backlog, I think you would have an interest to accept such a transaction= . >> >> > So I'm not sure if those two rules are compatible with miners >> incentives... >> >> The same argument can be made for the 26th descendant of a mempool >> transaction; it's also not entirely incentive-compatible to reject it, b= ut >> that is not the *only* design goal in mempool policy. Of course, the >> difference here is that the 25-descendant limit rule is a sensible DoS >> protection, while this 1-descendant limit rule is more of a "help the >> Bitcoin ecosystem" policy, just like CPFP carve-out, dust limit, etc. I = can >> of course understand why not everyone would be in favor of this, but I d= o >> think it's worth it. >> >> > > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be >> > > larger than 1000 virtual bytes. >> >> > If I understand correctly the 1000 vb upper bound rational, it would b= e >> to constraint the pinning counterparty to attach a high fee to a child d= ue >> to the limited size, if they would like this transaction to be stuck in = the >> network mempools. By doing so this child has high odds to confirm. >> >> Yeah exactly, the "Rule 3 pin" is done by adding a child that's high-fee >> (so you have to pay that much to evict it). Because they *don't* want th= is >> tx to confirm, normally, this child would be really large. If they only >> have 1000vB for the child, they can't increase the replacement cost with= out >> also fee-bumping the transaction to make it confirm faster. >> >> > As of today, I think yes you can already fingerprint LN transactions o= n >> the spec-defined amount value of the anchor outputs, 330 sats. There is >> always one of them on post-anchor commitment transactions. And sadly I >> would say we'll always have tricky fingerprints leaking from unilateral = LN >> closures such as HTLC/PTLC timelocks... >> >> > I agree with you, this isn't worse than today, unilateral closes will >> probably always be identifiable on-chain. >> >> Great to hear that there is no privacy worsening! >> >> Best, >> Gloria >> >> On Mon, Sep 26, 2022 at 5:02 PM Greg Sanders >> wrote: >> >>> Bastien, >>> >>> > This may be already covered by the current package RBF logic, in that >>> scenario we are simply replacing [ParentTx, ChildTx1] with >>> [ParentTx, ChildTx2] that pays more fees, right? >>> >>> For clarification, package RBF is ParentTx*s*(plural), and >>> ChildTx(singular), so it might be a bit more complicated than we're >>> thinking, and currently the V3 proposal would first de-duplicate the >>> ParentTx based on what is in the mempool, then look at the "rest" of th= e >>> transactions as a package, then individually. Not the same, not sure ho= w >>> different. I'll defer to experts. >>> >>> Best, >>> Greg >>> >>> On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> Thanks Gloria for this great post. >>>> >>>> This is very valuable work for L2 contracts, and will greatly improve >>>> their security model. >>>> >>>> > "Only 1 anchor output? What if I need to bump counterparty's >>>> commitment tx in mempool?" >>>> > You won't need to fee-bump a counterparty's commitment tx using CPFP= . >>>> > You would just package RBF it by attaching a high-feerate child to >>>> > your commitment tx. >>>> >>>> Note that we can also very easily make that single anchor spendable by >>>> both participants (or even anyone), so if you see your counterparty's >>>> commitment in your mempool, you can bump it without publishing your >>>> own commitment, which is quite desirable (your own commitment tx has >>>> CSV delays on your outputs, whereas your counterparty's commitment tx >>>> doesn't). >>>> >>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN >>>> transactions based on nVersion?" >>>> >>>> I agree with you, this isn't worse than today, unilateral closes will >>>> probably always be identifiable on-chain. >>>> >>>> > Would kind of be nice if package RBF would detect a "sibling output >>>> spend" >>>> > conflict, and knock it out of the mempool via the other replacement >>>> rules? >>>> > Getting rid of the requirement to 1 block csv lock every output woul= d >>>> be >>>> > quite nice from a smart contracting composability point of view. >>>> >>>> +1, that would be very neat! >>>> >>>> This may be already covered by the current package RBF logic, in that >>>> scenario we are simply replacing [ParentTx, ChildTx1] with >>>> [ParentTx, ChildTx2] that pays more fees, right? >>>> >>>> > 1) I do think that we should seriously consider allowing OP_TRUE to >>>> become >>>> > a standard script type as part of this policy update. If pinning is >>>> solved, >>>> > then there's no reason to require all those extra bytes for "binding= " >>>> an >>>> > anchor to a specific wallet/user. We can save quite a few bytes by >>>> having >>>> > the input be empty of witness data. >>>> > 2) If we allow for a single dust-value(0 on up) output which is >>>> immediately >>>> > spent by the package, anchors become even easier to to design. No >>>> value has >>>> > to be "sapped" from contract participants to make an anchor output. >>>> There's >>>> > more complications for this, such as making sure the parent >>>> transaction is >>>> > dropped if the child spend is dropped, but maybe it's worth the >>>> squeeze. >>>> >>>> I also think both of these could be quite useful. This would probably >>>> always >>>> be used in combination with a parent transaction that pays 0 fees, so >>>> the >>>> 0-value output would always be spent in the same block. >>>> >>>> But this means we could end up with 0-value outputs in the utxo set, i= f >>>> for >>>> some reason the parent tx is CPFP-ed via another output than the >>>> 0-value one, >>>> which would be a utxo set bloat issue. But I'd argue that we're probab= ly >>>> already creating utxo set bloat with the 330 sat anchor outputs >>>> (especially >>>> since we use two of them, but only one is usually spent), so it would >>>> probably be *better* than what we're doing today. >>>> >>>> Thanks, >>>> Bastien >>>> >>>> Le lun. 26 sept. 2022 =C3=A0 03:22, Antoine Riard via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : >>>> >>>>> Hi Gloria, >>>>> >>>>> Thanks for the progress on package RBF, few early questions. >>>>> >>>>> > 2. Any descendant of an unconfirmed V3 transaction must also be V3. >>>>> >>>>> > 3. An unconfirmed V3 transaction cannot have more than 1 descendant= . >>>>> >>>>> If you're a miner and you receive a non-V3, second descendant of an >>>>> unconfirmed V3 transaction, if the offered fee is in the top mempool >>>>> backlog, I think you would have an interest to accept such a transact= ion. >>>>> >>>>> So I'm not sure if those two rules are compatible with miners >>>>> incentives... >>>>> >>>>> > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be >>>>> > larger than 1000 virtual bytes. >>>>> >>>>> If I understand correctly the 1000 vb upper bound rational, it would >>>>> be to constraint the pinning counterparty to attach a high fee to a c= hild >>>>> due to the limited size, if they would like this transaction to be st= uck in >>>>> the network mempools. By doing so this child has high odds to confir= m. >>>>> >>>>> I still wonder if this compatible with miner incentives in period of >>>>> empty mempools, in the sense that if you've already a V3 transaction = of >>>>> size 100Kvb offering 2 sat/vb, it's more interesting than a V3 replac= ement >>>>> candidate of size 1000 vb offering 10 sat/vb. It could be argued the = former >>>>> should be conserved. >>>>> >>>>> (That said, the hard thing with any replacement strategy we might >>>>> evict a parent transaction *now* to which is attached a high-feerate = child >>>>> *latter* making for a utxo considered the best ancestor set. Maybe in= the >>>>> long-term miners should keep every transaction ever accepted...) >>>>> >>>>> > (Lower bound) the smaller this limit, the fewer UTXOs a child may u= se >>>>> > to fund this fee-bump. For example, only allowing the V3 child to >>>>> have >>>>> > 2 inputs would require L2 protocols to manage a wallet with >>>>> high-value >>>>> > UTXOs and make batched fee-bumping impossible. However, as the >>>>> > fee-bumping child only needs to fund fees (as opposed to payments), >>>>> > just a few UTXOs should suffice. >>>>> >>>>> Reminder for L2 devs, batched fee-bumping of time-sensitive >>>>> confirmations of commitment transactions is unsafe, as the counterpar= ty >>>>> could enter in a "cat-and-mouse" game to replace one of the batch ele= ment >>>>> at each block to delay confirmation of the remaining elements in the = batch, >>>>> I think. >>>>> >>>>> On the other hand, I wonder if we wouldn't want a higher bound. LN >>>>> wallets are likely to have one big UTXO in their fee-bumping reserve = pool, >>>>> as the cost of acquiring UTXO is non-null and in the optimistic case,= you >>>>> don't need to do unilateral closure. Let's say you close dozens of ch= annels >>>>> at the same time, a UTXO pool management strategy might be to fan-out= the >>>>> first spends UTXOs in N fan-out outputs ready to feed the remaining >>>>> in-flight channels. >>>>> >>>>> > 1. The rule around unconfirmed inputs was >>>>> > originally "A package may include new unconfirmed inputs, but the >>>>> > ancestor feerate of the child must be at least as high as the >>>>> ancestor >>>>> > feerates of every transaction being replaced." >>>>> >>>>> Note, I think we would like this new RBF rule to also apply to single >>>>> transaction package, e.g second-stage HTLC transactions, where a >>>>> counterparty pins a HTLC-preimage by abusing rule 3. In that case, th= e >>>>> honest LN node should be able to broadcast a "at least as high ancest= or >>>>> feerate" HTLC-timeout transaction. With `option_anchor_outputs" there= is no >>>>> unconfirmed ancestor to replace, as the commitment transaction, whate= ver >>>>> the party it is originating from, should already be confirmed. >>>>> >>>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN >>>>> transactions based on nVersion?" >>>>> >>>>> As of today, I think yes you can already fingerprint LN transactions >>>>> on the spec-defined amount value of the anchor outputs, 330 sats. Th= ere is >>>>> always one of them on post-anchor commitment transactions. And sadly = I >>>>> would say we'll always have tricky fingerprints leaking from unilater= al LN >>>>> closures such as HTLC/PTLC timelocks... >>>>> >>>>> > "Can a V2 transaction replace a V3 transaction and vice versa?" >>>>> >>>>> IIUC, a V3 package could replace a V2 package, with the benefit of th= e >>>>> new package RBF rules applied. I think this would be a significant >>>>> advantage for LN, as for the current ~85k of opened channels, the old= V2 >>>>> states shouldn't be pinning vectors. Currently, commitment transactio= ns >>>>> signal replaceability. >>>>> >>>>> Le ven. 23 sept. 2022 =C3=A0 11:26, Gloria Zhao via bitcoin-dev < >>>>> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I'm writing to propose a very simple set of mempool/transaction rela= y >>>>>> policies intended to aid L2/contract protocols. I realized that >>>>>> the previously proposed Package Mempool Accept package RBF [1] >>>>>> had a few remaining problems after digging into the RBF logic more >>>>>> [2]. >>>>>> This additional set of policies solves them without requiring a huge >>>>>> RBF overhaul. >>>>>> >>>>>> I've written an implementation (and docs) for Bitcoin Core: >>>>>> https://github.com/bitcoin/bitcoin/pull/25038 >>>>>> >>>>>> (You may notice that this proposal incorporates feedback on the PR - >>>>>> thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony T= owns, >>>>>> and others.) >>>>>> >>>>>> If you are interested in using package RBF/relay to bump presigned >>>>>> transactions, I think you may be interested in reviewing this >>>>>> proposal. >>>>>> This should solve Rule 3 pinning and perhaps allow us >>>>>> to get rid of CPFP carve-out (yay!). I'm keen to hear if people find >>>>>> the 1-anchor-output, 1000vB child limit too restrictive. Also, if yo= u >>>>>> find a >>>>>> pinning attack or something that makes it unusable for you, I would >>>>>> really really like to know. >>>>>> >>>>>> Note that transactions with nVersion=3D3 ("V3 transactions") are >>>>>> currently non-standard in Bitcoin Core. That means **anything that w= as >>>>>> standard before this policy change would still be standard >>>>>> afterwards.** If you don't want your transactions to be subject to >>>>>> these rules, just continue whatever you're doing and don't use >>>>>> nVersion=3D3. AFAICT this shouldn't break anything, but let me know = if >>>>>> this would be disruptive for you? >>>>>> >>>>>> **New Policies:** >>>>>> >>>>>> This includes: >>>>>> - a set of additional policy rules applying to V3 transactions >>>>>> - modifications to package RBF rules >>>>>> >>>>>> **V3 transactions:** >>>>>> >>>>>> Existing standardness rules apply to V3 (e.g. min/max tx weight, >>>>>> standard output types, cleanstack, etc.). The following additional >>>>>> rules apply to V3: >>>>>> >>>>>> 1. A V3 transaction can be replaced, even if it does not signal BIP1= 25 >>>>>> replaceability. (It must also meet the other RBF rules around fee= s, >>>>>> etc. for replacement to happen). >>>>>> >>>>>> 2. Any descendant of an unconfirmed V3 transaction must also be V3. >>>>>> >>>>>> *Rationale*: Combined with Rule 1, this gives us the property of >>>>>> "inherited" replaceability signaling when descendants of unconfirmed >>>>>> transactions are created. Additionally, checking whether a transacti= on >>>>>> signals replaceability this way does not require mempool traversal, >>>>>> and does not change based on what transactions are mined. It also >>>>>> makes subsequent rules about descendant limits much easier to check. >>>>>> >>>>>> *Note*: The descendant of a *confirmed* V3 transaction does not need >>>>>> to be V3. >>>>>> >>>>>> 3. An unconfirmed V3 transaction cannot have more than 1 descendant. >>>>>> >>>>>> *Rationale*: (Upper bound) the larger the descendant limit, the more >>>>>> transactions may need to be replaced. This is a problematic pinning >>>>>> attack, i.e., a malicious counterparty prevents the transaction from >>>>>> being replaced by adding many descendant transactions that aren't >>>>>> fee-bumping. >>>>>> >>>>>> (Lower bound) at least 1 descendant is required to allow CPFP of the >>>>>> presigned transaction. The contract protocol can create presigned >>>>>> transactions paying 0 fees and 1 output for attaching a CPFP at >>>>>> broadcast time ("anchor output"). Without package RBF, multiple anch= or >>>>>> outputs would be required to allow each counterparty to fee-bump any >>>>>> presigned transaction. With package RBF, since the presigned >>>>>> transactions can replace each other, 1 anchor output is sufficient. >>>>>> >>>>>> 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be >>>>>> larger than 1000 virtual bytes. >>>>>> >>>>>> *Rationale*: (Upper bound) the larger the descendant size limit, the >>>>>> more vbytes may need to be replaced. With default limits, if the chi= ld >>>>>> is e.g. 100,000vB, that might be an additional 100,000sats (at >>>>>> 1sat/vbyte) or more, depending on the feerate. >>>>>> >>>>>> (Lower bound) the smaller this limit, the fewer UTXOs a child may us= e >>>>>> to fund this fee-bump. For example, only allowing the V3 child to ha= ve >>>>>> 2 inputs would require L2 protocols to manage a wallet with high-val= ue >>>>>> UTXOs and make batched fee-bumping impossible. However, as the >>>>>> fee-bumping child only needs to fund fees (as opposed to payments), >>>>>> just a few UTXOs should suffice. >>>>>> >>>>>> With a limit of 1000 virtual bytes, depending on the output types, t= he >>>>>> child can have 6-15 UTXOs, which should be enough to fund a fee-bump >>>>>> without requiring a carefully-managed UTXO pool. With 1000 virtual >>>>>> bytes as the descendant limit, the cost to replace a V3 transaction >>>>>> has much lower variance. >>>>>> >>>>>> *Rationale*: This makes the rule very easily "tacked on" to existing >>>>>> logic for policy and wallets. A transaction may be up to 100KvB on i= ts >>>>>> own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants >>>>>> (`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 transaction >>>>>> in the mempool is 100KvB, its descendant can only be 1000vB, even if >>>>>> the policy is 10KvB. >>>>>> >>>>>> **Package RBF modifications:** >>>>>> >>>>>> 1. The rule around unconfirmed inputs was >>>>>> originally "A package may include new unconfirmed inputs, but the >>>>>> ancestor feerate of the child must be at least as high as the ancest= or >>>>>> feerates of every transaction being replaced." >>>>>> >>>>>> The package may still include new unconfirmed inputs. However, >>>>>> the new rule is modified to be "The minimum between package feerate >>>>>> and ancestor feerate of the child is not lower than the individual >>>>>> feerates of all directly conflicting transactions and the ancestor >>>>>> feerates of all original transactions." >>>>>> >>>>>> *Rationale*: We are attempting to ensure that the replacement >>>>>> transactions are not less incentive-compatible to mine. However, a >>>>>> package/transaction's ancestor feerate is not perfectly representati= ve >>>>>> of its incentive compatibility; it may overestimate (some subset of >>>>>> the ancestors could be included by itself if it has other high-feera= te >>>>>> descendants or are themselves higher feerate than this >>>>>> package/transaction). Instead, we use the minimum between the packag= e >>>>>> feerate and ancestor feerate of the child as a more conservative val= ue >>>>>> than what was proposed originally. >>>>>> >>>>>> 2. A new rule is added, requiring that all package transactions with >>>>>> mempool conflicts to be V3. This also means the "sponsoring" >>>>>> child transaction must be V3. >>>>>> >>>>>> *Note*: Combined with the V3 rules, this means the package must be >>>>>> a child-with-parents package. Since package validation is only >>>>>> attempted if the transactions do not pay sufficient fees to be >>>>>> accepted on their own, this effectively means that only V3 >>>>>> transactions can pay to replace their ancestors' conflicts, and only >>>>>> V3 transactions' replacements may be paid for by a descendant. >>>>>> >>>>>> *Rationale*: 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. It >>>>>> may be fine to allow any ancestor package, but it's more difficult >>>>>> to account for all of the possibilities. For example, it gets much >>>>>> harder to see that we're applying the descendant limits correctly if >>>>>> the package has a gnarly, many-generation, non-tree shape. I'm also >>>>>> not sure if this policy is 100% incentive-compatible if the sponsor >>>>>> is not a direct descendant of the sponsee. >>>>>> >>>>>> Please see doc/policy/version3_transactions.md and >>>>>> doc/policy/packages.md in the PR for the full set of rules. >>>>>> >>>>>> **Intended usage for LN:** >>>>>> >>>>>> Commitment transactions 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. I'm going to >>>>>> call the broadcasted commitment tx "the parent" and the attached >>>>>> fee-bumping tx "the child." >>>>>> >>>>>> - This child must be V3. >>>>>> - This child must be at most 1000vB. Note this restricts the >>>>>> number of inputs you can use to fund the fee bump. Depending >>>>>> on the output types, this is around 6-15. >>>>>> - 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. Do not try to attach a grandchil= d. >>>>>> >>>>>> Otherwise, never try to spend from an unconfirmed V3 transaction. Th= e >>>>>> descendant limits for V3 transactions are very restrictive. >>>>>> >>>>>> **Expected Questions:** >>>>>> >>>>>> "Does this fix Rule 3 Pinning?" >>>>>> Yes. The V3 descendant limit restricts both you and your counterpart= y. >>>>>> Assuming nodes adopted this policy, you may reasonably assume that y= ou >>>>>> only need to replace the commitment transaction + up to 1000vB. >>>>>> >>>>>> "Only 1 anchor output? What if I need to bump counterparty's >>>>>> commitment tx in mempool?" >>>>>> You won't need to fee-bump a counterparty's commitment tx using CPFP= . >>>>>> You would just package RBF it by attaching a high-feerate child to >>>>>> your commitment tx. >>>>>> >>>>>> "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. IIUC, unilateral closes are already >>>>>> obvious LN transactions because of the HTLC inputs. For e.g. >>>>>> cooperative closes and opens, I think it makes sense to continue usi= ng >>>>>> V2. So, unless I'm missing something, this shouldn't make it worse. >>>>>> >>>>>> "So a V3 transaction that doesn't signal BIP125 replaceability is >>>>>> replaceable? Is that a backward compatibility issue?" >>>>>> Yes it's replaceable. It's not an issue AFAICT because, >>>>>> under previous policy, the V3 transaction wouldn't have been >>>>>> in the mempool in the first place. >>>>>> >>>>>> "Can a V2 transaction replace a V3 transaction and vice versa?" >>>>>> Yes, otherwise someone can use V3 transactions to censor V2 >>>>>> transactions spending shared inputs. Note if the >>>>>> original V3 transaction has an unconfirmed V3 parent, this would >>>>>> violate the "inherited V3" rule and would be rejected. >>>>>> >>>>>> Thanks for reading! Feedback and review would be much appreciated. >>>>>> >>>>>> [1]: >>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Septemb= er/019464.html >>>>>> [2]: >>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January= /019817.html >>>>>> >>>>>> Best, >>>>>> Gloria >>>>>> _______________________________________________ >>>>>> bitcoin-dev mailing list >>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> --000000000000075e2705e9d1e0c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Right, good catch, this does require new logic to han= dle this case.
As Gloria points out, this should be doable, and is defin= itely worth
adding (those CSV 1 on every other output are really hacky, = glad to
find a way to get rid of them).

For the recor= d, it turns out ephemeral anchors=C2=A0+ v3 solves this already, as the anc= hor must be spent, and the parent tx may only have one child. Somehow I mis= sed this implication for a few months. It's great news if we can direct= ly source fees from any output claimable, including HTLCs!

<= div class=3D"gmail_quote">
On Thu, Sep= 29, 2022 at 5:15 AM Bastien TEINTURIER <bastien@acinq.fr> wrote:
Hi Gloria, Greg,

> I interp= ret most of the discussion around limitations as ideas for
> future i= mprovements rather than criticisms of the proposal

As far as I'm= concerned, definitely!

My current understanding is that the main ch= ange/improvement that would
make sense here is restricting the whole v3 = package's size (instead of
just the child) via committing to a speci= fic value in the taproot annex
(also note that it's probably not jus= t the v3 package's size, it should
be the whole unconfirmed package = including potential v2 unconfirmed
ancestors).

While I think this= would be very valuable and would like to see this
happen, I believe tha= t can be done in a second, separate step since this
would make relay pol= icy stricter (some v3 transactions that previously
propagated wouldn'= ;t propagate under this new rule). As long as you are
able to find a pat= h to miners through upgraded peers that use this annex
approach, you sho= uld be able to resolve ACP pinning issues?

I'm curious to know h= ow other people feel about that: is it ok to do
later or should we try t= o implement this for the first release of v3
transactions?

The ot= her change mentioned (making OP_TRUE standard and allowing outputs
that = are below dust) can be added later, as those won't be standard untilwe start allowing them, so there shouldn't be any backwards-compatibil= ity
issue with postponing this change. But maybe it's still worth ha= ving from
the get-go, even though it may take a bit more time? Again, I&= #39;m curious to
have other people's opinion here, I'd be happy = to get all of those directly
in the first release of v3 transactions, bu= t I don't know how much
implementation will have to go into that.
> For clarification, package RBF is ParentTx*s*(plural), and ChildT= x(singular),
> so it might be a bit more complicated than we're t= hinking

Right, good catch, this does require new logic to handle thi= s case.
As Gloria points out, this should be doable, and is definitely w= orth
adding (those CSV 1 on every other output are really hacky, glad to=
find a way to get rid of them).

Thanks,
Bastien

Le=C2=A0lun. 2= 6 sept. 2022 =C3=A0=C2=A018:48, Gloria Zhao <gloriajzhao@gmail.com> a =C3=A9crit= =C2=A0:
Hi Greg, Antoine, Bastien, =C2=A0
=C2=A0
Thanks very much f= or the feedback! I interpret most of the discussion around limitations as i= deas for future improvements rather than criticisms of the proposal (please= correct me if I'm wrong). I'll try to respond to as much as possib= le.

Also I realize that I didn't contextualize this proposal cle= arly enough; it is very tailored for LN Penalty and definitely doesn't = close all pinning attacks possible (sorry for confusing anyone). I also agr= ee that some bits can be a little ugly or tack-on; I would definitely prefe= r a comprehensive RBF revamp to fix all our problems and enable other fee-b= umping strategies such as sign-ANYONECANPAY-then-bring-your-own-fees-by-add= ing-inputs-at-broadcast. I was hoping to get some ideas with the "RBF = Improvements" post in January, but it doesn't seem like we're = much closer to a workable proposal. I think this is a minimally-invasive st= ep that works for Lightning today, a small fix similar to CPFP carve out.
> As you likely know from previous discussions the biggest scenari= o this does not fix in my estimation is ANYONECANPAY situations. If the par= ent transaction can be "inflated" by tacking on additional inputs= , this means the total weight of the parent tx lowers the effective feerate= of the package. =C2=A0
=C2=A0
(For more context to other readers I = wrote an explanation for this in "SIGHASH_ANYONECANPAY Pinning" s= ection of RBF ML post).=C2=A0 Yes, this unfortunately doesn't fix any o= f the existing pinning attacks for single transaction RBF but also doesn= 9;t make them worse. This boils down to adding an incentive compatibility r= ule that ensures you can't replace a transaction with something that wi= ll confirm slower. Package RBF has an ancestor feerate-based rule for this = (note it is quite conservative and not perfect).

So in the scenario = above with the "inflated" parent that was signed ACP, the replace= ment would be rejected because the package ancestor feerate is lower than t= he feerate of what is being replaced. But it is imperfect (explained below)= and thus I wouldn't recommend it for single transaction replacement. S= o that attack still exists for single transactions, yes. =C2=A0

The = strategy of using ACP to bring-your-own-fees has its own challenges but hop= efully has no current use cases as you say. AFAIK LN Penalty is not affecte= d by this since it doesn't use ACP, though obviously I agree we should = fix it for the future.

So when I said "this is intended for fee= -bumping presigned txns in contracting protocols," I should have said = "this is intended for fee-bumping presigned txns specifically using CP= FP and anchor outputs." Apologies for forgetting to contextualize, I&#= 39;ve been sitting on this for too long.
=C2=A0
> The other scena= rio it doesn't really fix is where HTLC/commitment-like transactions ar= e being resolved in a batch, but due to relative time constraints, you may = want to accelerate some and not others. Now you must pay higher rates to re= place all of the transaction bumps. This is a "self-pin" and &quo= t;get good at utxos noob" type problem, but it's something that ax= ing rule#3 in favor of a Replace-by-ancestor-feerate system would get us. = =C2=A0
=C2=A0
I understand you to mean "if you don't have e= nough UTXOs and you're forced to batch-bump, you over-pay because you n= eed to bring them all to the highest target feerate." Isn't this k= ind of separate, wallet-related problem? Contracting or not, surely every w= allet needs to have enough UTXOs to not batch transactions that shouldn'= ;t be batched... I don't see how a replace-by-ancestor-feerate policy w= ould make any difference for this?

Also in general I'd like to r= eiterate that ancestor feerate is not a panacea to all our RBF incentive co= mpatibility concerns. Like individual feerate, unless we run the mining alg= orithm, it cannot tell us exactly how quickly this transaction would be min= ed.

We're estimating the incentive compatibility of the original= transaction(s) and replacement transaction(s), with the goal of not lettin= g a transaction replace something that would have been more incentive compa= tible to mine. As such, we don't want to overestimate how good the repl= acement is, and we don't want to underestimate how good the original tr= ansactions are. This rule "The minimum between package feerate and anc= estor feerate of the child is not lower than the individual feerates of all= directly conflicting transactions and the ancestor feerates of all origina= l transactions" is a conservative estimate.

> Would kind of = be nice if package RBF would detect a "sibling output spend" conf= lict, and knock it out of the mempool via the other replacement rules? Gett= ing rid of the requirement to 1 block csv lock every output would be quite = nice from a smart contracting composability point of view.

Interesti= ng, so when a transaction hits a mempool tx's descendant limit, we cons= ider evicting one of its descendants in favor of this transaction, based on= the RBF rules.
Cool idea! After chewing on this for a bit, I think this= *also* just boils down to the fact that RBF should require replacements to= be better mining candidates. As in, if we added this policy and it can mak= e us evict the sibling and accept a transaction with a bunch of low-feerate= ancestor junk, it would be a new pinning vector.
=C2=A0
> If yo= u're a miner and you receive a non-V3, second descendant of an unconfir= med V3 transaction, if the offered fee is in the top mempool backlog, I thi= nk you would have an interest to accept such a transaction. =C2=A0 =C2=A0 = =C2=A0
> So I'm not sure if those two rules are compatible with m= iners incentives... =C2=A0
=C2=A0
The same argument can be made for = the 26th descendant of a mempool transaction; it's also not entirely in= centive-compatible to reject it, but that is not the *only* design goal in = mempool policy. Of course, the difference here is that the 25-descendant li= mit rule is a sensible DoS protection, while this 1-descendant limit rule i= s more of a "help the Bitcoin ecosystem" policy, just like CPFP c= arve-out, dust limit, etc. I can of course understand why not everyone woul= d be in favor of this, but I do think it's worth it.
=C2=A0
>= > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be =C2= =A0 =C2=A0
> > =C2=A0 =C2=A0larger than 1000 virtual bytes. =C2=A0= =C2=A0
=C2=A0 =C2=A0
> If I understand correctly the 1000 vb uppe= r bound rational, it would be to constraint the pinning counterparty to att= ach a high fee to a child due to the limited size, if they would like this = transaction to be stuck in the network mempools. By doing so=C2=A0 this chi= ld has high odds to confirm. =C2=A0
=C2=A0
Yeah exactly, the &q= uot;Rule 3 pin" is done by adding a child that's high-fee (so you = have to pay that much to evict it). Because they *don't* want this tx t= o confirm, normally, this child would be really large. If they only have 10= 00vB for the child, they can't increase the replacement cost without al= so fee-bumping the transaction to make it confirm faster.=C2=A0

&= gt; As of today, I think yes you can already fingerprint LN transactions on= the=C2=A0 spec-defined amount value of the anchor outputs, 330 sats. There= is always one of them on post-anchor commitment transactions. And sadly I = would say we'll always have tricky fingerprints leaking from unilateral= LN closures such as HTLC/PTLC timelocks... =C2=A0

&= gt; I agree with you, this isn't worse than today, unilateral closes wi= ll
probably always be identifiable on-chain.

Great to he= ar that there is no privacy worsening!

Best, =C2=A0
Gloria

On = Mon, Sep 26, 2022 at 5:02 PM Greg Sanders <gsanders87@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Bastien,<= div>
> This may be already covered by the current package = RBF logic, in that
scenario we are simply replacing [ParentTx, ChildTx= 1] with
[ParentTx, ChildTx2] that pays more fees, right?

<= div>For clarification, package RBF is ParentTx*s*(plural), and ChildTx(sing= ular), so it might be a bit more complicated than we're thinking, and c= urrently the V3 proposal would first de-duplicate=C2=A0the ParentTx based o= n what is in the mempool, then look at the "rest" of the transact= ions as a package, then individually. Not the same, not sure how different.= I'll defer to experts.

Best,
Greg

On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:
Thanks Gloria for th= is great post.

This is very valuable work for L2 contracts, and will= greatly improve
their security model.

> "Only 1 anchor o= utput? What if I need to bump counterparty's commitment tx in mempool?&= quot;
> You won't need to fee-bump a counterparty's commitmen= t tx using CPFP.
> You would just package RBF it by attaching a high-= feerate child to
> your commitment tx.

Note that we can also v= ery easily make that single anchor spendable by
both participants (or ev= en anyone), so if you see your counterparty's
commitment in your mem= pool, you can bump it without publishing your
own commitment, which is q= uite desirable (your own commitment tx has
CSV delays on your outputs, w= hereas your counterparty's commitment tx
doesn't).

> &= quot;Is this a privacy issue, i.e. doesn't it allow fingerprinting LNtransactions based on nVersion?"

I agree with you, this isn&#= 39;t worse than today, unilateral closes will
probably always be identif= iable on-chain.

> Would kind of be nice if package RBF would dete= ct a "sibling output spend"
> conflict, and knock it out of= the mempool via the other replacement rules?
> Getting rid of the re= quirement to 1 block csv lock every output would be
> quite nice from= a smart contracting composability point of view.

+1, that would be = very neat!

This may be already covered by the current package RBF lo= gic, in that
scenario we are simply replacing [ParentTx, ChildTx1] with<= br>[ParentTx, ChildTx2] that pays more fees, right?

> 1) I do thi= nk that we should seriously consider allowing OP_TRUE to become
> a s= tandard script type as part of this policy update. If pinning is solved,> then there's no reason to require all those extra bytes for "= ;binding" an
> anchor to a specific wallet/user. We can save qui= te a few bytes by having
> the input be empty of witness data.
>= ; 2) If we allow for a single dust-value(0 on up) output which is immediate= ly
> spent by the package, anchors become even easier to to design. N= o value has
> to be "sapped" from contract participants to = make an anchor output. There's
> more complications for this, suc= h as making sure the parent transaction is
> dropped if the child spe= nd is dropped, but maybe it's worth the squeeze.

I also think bo= th of these could be quite useful. This would probably always
be used in= combination with a parent transaction that pays 0 fees, so the
0-value = output would always be spent in the same block.

But this means we co= uld end up with 0-value outputs in the utxo set, if for
some reason the = parent tx is CPFP-ed via another output than the 0-value one,
which woul= d be a utxo set bloat issue. But I'd argue that we're probably
a= lready creating utxo set bloat with the 330 sat anchor outputs (especially<= br>since we use two of them, but only one is usually spent), so it wouldprobably be *better* than what we're doing today.

Thanks,
Ba= stien

Le=C2=A0lun. 26 sept. 2022 =C3=A0=C2=A003:22, Antoine Riard via bitcoi= n-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2= =A0:
Hi Gloria,

Thanks for the progress on package RBF, few early q= uestions.

> 2. Any descendant of an unconfirmed V3 transaction mu= st also be V3.

> 3. An unconfirmed V3 transaction cannot have mor= e than 1 descendant.

If you're a miner and you receive a non-V3,= second descendant of an unconfirmed V3 transaction, if the offered fee is = in the top mempool backlog, I think you would have an interest to accept su= ch a transaction.

So I'm not sure if those two rules are compati= ble with miners incentives...

> 4. A V3 transaction that has an u= nconfirmed V3 ancestor cannot be
> =C2=A0 =C2=A0larger than 1000 virt= ual bytes.

If I understand correctly the 1000 vb upper bound rationa= l, it would be to constraint the pinning counterparty to attach a high fee = to a child due to the limited size, if they would like this transaction to = be stuck in the network mempools. By doing so=C2=A0 this child has high odd= s to confirm.

I still wonder if this compatible with miner incentive= s in period of empty mempools, in the sense that if you've already a V3= transaction of size 100Kvb offering 2 sat/vb, it's more interesting th= an a V3 replacement candidate of size 1000 vb offering 10 sat/vb. It could = be argued the former should be conserved.

(That said, the hard thing= with any replacement strategy we might evict a parent transaction *now* to= which is attached a high-feerate child *latter* making for a utxo consider= ed the best ancestor set. Maybe in the long-term miners should keep every t= ransaction ever accepted...)

> (Lower bound) the smaller this lim= it, the fewer UTXOs a child may use
> to fund this fee-bump. For exam= ple, only allowing the V3 child to have
> 2 inputs would require L2 p= rotocols to manage a wallet with high-value
> UTXOs and make batched = fee-bumping impossible. However, as the
> fee-bumping child only need= s to fund fees (as opposed to payments),
> just a few UTXOs should su= ffice.

Reminder for L2 devs, batched fee-bumping of time-sensitive c= onfirmations of commitment transactions is unsafe, as the counterparty coul= d enter in a "cat-and-mouse" game to replace one of the batch ele= ment at each block to delay confirmation of the remaining elements in the b= atch, I think.

On the other hand, I wonder if we wouldn't want a= higher bound. LN wallets are likely to have one big UTXO in their fee-bump= ing reserve pool, as the cost of acquiring UTXO is non-null and in the opti= mistic case, you don't need to do unilateral closure. Let's say you= close dozens of channels at the same time, a UTXO pool management strategy= might be to fan-out the first spends UTXOs in N fan-out outputs ready to f= eed the remaining in-flight channels.

> 1. The rule around unconf= irmed inputs was
> originally "A package may include new unconfi= rmed inputs, but the
> ancestor feerate of the child must be at least= as high as the ancestor
> feerates of every transaction being replac= ed."

Note, I think we would like this new RBF rule to also appl= y to single transaction package, e.g second-stage HTLC transactions, where = a counterparty pins a HTLC-preimage by abusing rule 3. In that case, the ho= nest LN node should be able to broadcast a "at least as high ancestor = feerate" HTLC-timeout transaction. With `option_anchor_outputs" t= here is no unconfirmed ancestor to replace, as the commitment transaction, = whatever the party it is originating from, should already be confirmed.
=
> "Is this a privacy issue, i.e. doesn't it allow fingerpri= nting LN
transactions based on nVersion?"

As of today, I thi= nk yes you can already fingerprint LN transactions on the=C2=A0 spec-define= d amount value of the anchor outputs, 330 sats. There is always one of them= on post-anchor commitment transactions. And sadly I would say we'll al= ways have tricky fingerprints leaking from unilateral LN closures such as H= TLC/PTLC timelocks...

> "Can a V2 transaction replace a V3 t= ransaction and vice versa?"

IIUC, a V3 package could replace a = V2 package, with the benefit of the new package RBF rules applied. I think = this would be a significant advantage for LN, as for the current ~85k of op= ened channels, the old V2 states shouldn't be pinning vectors. Currentl= y, commitment transactions signal replaceability.

Le=C2=A0ven. 23 sept= . 2022 =C3=A0=C2=A011:26, Gloria Zhao via bitcoin-dev <bitcoin-dev@lists= .linuxfoundation.org> a =C3=A9crit=C2=A0:
Hi everyone,

I'= ;m writing to propose a very simple set of mempool/transaction relay
pol= icies intended to aid L2/contract protocols. I realized that
the previou= sly proposed Package Mempool Accept package RBF [1]
had a few remai= ning problems after digging into the RBF logic more [2].
This add= itional set of policies solves them without requiring a huge RBF overhaul.<= br>

I've written an implementation (and docs) for Bitcoin Core= :
https://github.com/bitcoin/bitcoin/pull/25038

(You may not= ice that this proposal incorporates feedback on the PR - thanks Suhas Daftu= ar, Gregory Sanders, Bastien Teinturier, Anthony Towns, and others.)
If you are interested in using package RBF/relay to bump presigned
tran= sactions, I think you may be interested in reviewing this proposal.
This= should solve Rule 3 pinning and perhaps allow us
to get rid of CPFP car= ve-out (yay!). I'm keen to hear if people find
the 1-anchor-output, = 1000vB child limit too restrictive. Also, if you find a
pinning attack o= r something that makes it unusable for you, I would
really really like t= o know.

Note that transactions with nVersion=3D3 ("V3 transacti= ons") are
currently non-standard in Bitcoin Core. That means **anyt= hing that was
standard before this policy change would still be standard=
afterwards.** If you don't want your transactions to be subject to<= br>these rules, just continue whatever you're doing and don't usenVersion=3D3. AFAICT this shouldn't break anything, but let me know i= f
this would be disruptive for you?

**New Policies:**

This= includes:
- a set of additional policy rules applying to V3 transaction= s
- modifications to package RBF rules

**V3 transactions:**
Existing standardness rules apply to V3 (e.g. min/max tx weight,
stand= ard output types, cleanstack, etc.). The following additional
rules appl= y to V3:

1. A V3 transaction can be replaced, even if it does not si= gnal BIP125
=C2=A0 =C2=A0replaceability. (It must also meet the other RB= F rules around fees,
etc. for replacement to happen).

2. Any desc= endant of an unconfirmed V3 transaction must also be V3.

*Rationale*= : Combined with Rule 1, this gives us the property of
"inherited&qu= ot; replaceability signaling when descendants of unconfirmed
transaction= s are created. Additionally, checking whether a transaction
signals repl= aceability this way does not require mempool traversal,
and does not cha= nge based on what transactions are mined. It also
makes subsequent rules= about descendant limits much easier to check.

*Note*: The descendan= t of a *confirmed* V3 transaction does not need to be V3.

3. An unco= nfirmed V3 transaction cannot have more than 1 descendant.

*Rational= e*: (Upper bound) the larger the descendant limit, the more
transactions= may need to be replaced. This is a problematic pinning
attack, i.e., a = malicious counterparty prevents the transaction from
being replaced by a= dding many descendant transactions that aren't
fee-bumping.

(= Lower bound) at least 1 descendant is required to allow CPFP of the
pres= igned transaction. The contract protocol can create presigned
transactio= ns paying 0 fees and 1 output for attaching a CPFP at
broadcast time (&q= uot;anchor output"). Without package RBF, multiple anchor
outputs w= ould be required to allow each counterparty to fee-bump any
presigned tr= ansaction. With package RBF, since the presigned
transactions can replac= e each other, 1 anchor output is sufficient.

4. A V3 transaction tha= t has an unconfirmed V3 ancestor cannot be
=C2=A0 =C2=A0larger than 1000= virtual bytes.

*Rationale*: (Upper bound) the larger the descendant= size limit, the
more vbytes may need to be replaced. With default limit= s, if the child
is e.g. 100,000vB, that might be an additional 100,000sa= ts (at
1sat/vbyte) or more, depending on the feerate.

(Lower boun= d) the smaller this limit, the fewer UTXOs a child may use
to fund this = fee-bump. For example, only allowing the V3 child to have
2 inputs would= require L2 protocols to manage a wallet with high-value
UTXOs and make = batched fee-bumping impossible. However, as the
fee-bumping child only n= eeds to fund fees (as opposed to payments),
just a few UTXOs should suff= ice.

With a limit of 1000 virtual bytes, depending on the output typ= es, the
child can have 6-15 UTXOs, which should be enough to fund a fee-= bump
without requiring a carefully-managed UTXO pool. With 1000 virtual<= br>bytes as the descendant limit, the cost to replace a V3 transaction
h= as much lower variance.

*Rationale*: This makes the rule very easily= "tacked on" to existing
logic for policy and wallets. A trans= action may be up to 100KvB on its
own (`MAX_STANDARD_TX_WEIGHT`) and 101= KvB with descendants
(`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existi= ng V3 transaction
in the mempool is 100KvB, its descendant can only be 1= 000vB, even if
the policy is 10KvB.

**Package RBF modifications:*= *

1. The rule around unconfirmed inputs was
originally "A pa= ckage may include new unconfirmed inputs, but the
ancestor feerate of th= e child must be at least as high as the ancestor
feerates of every trans= action being replaced."

The package may still include new uncon= firmed inputs. However,
the new rule is modified to be "The minimum= between package feerate
and ancestor feerate of the child is not lower = than the individual
feerates of all directly conflicting transactions an= d the ancestor
feerates of all original transactions."

*Rati= onale*: We are attempting to ensure that the replacement
transactions ar= e not less incentive-compatible to mine. However, a
package/transaction&= #39;s ancestor feerate is not perfectly representative
of its incentive = compatibility; it may overestimate (some subset of
the ancestors could b= e included by itself if it has other high-feerate
descendants or are the= mselves higher feerate than this
package/transaction). Instead, we use t= he minimum between the package
feerate and ancestor feerate of the child= as a more conservative value
than what was proposed originally.

= 2. A new rule is added, requiring that all package transactions with
mem= pool conflicts to be V3. This also means the "sponsoring"
chil= d transaction must be V3.

*Note*: Combined with the V3 rules, this m= eans the package must be
a child-with-parents package. Since package val= idation is only
attempted if the transactions do not pay sufficient fees= to be
accepted on their own, this effectively means that only V3
tra= nsactions can pay to replace their ancestors' conflicts, and only
V3= transactions' replacements may be paid for by a descendant.

*Ra= tionale*: The fee-related rules are economically rational for
ancestor p= ackages, but not necessarily other types of packages.
A child-with-paren= ts package is a type of ancestor package. It
may be fine to allow any an= cestor package, but it's more difficult
to account for all of the po= ssibilities. For example, it gets much
harder to see that we're appl= ying the descendant limits correctly if
the package has a gnarly, many-g= eneration, non-tree shape. I'm also
not sure if this policy is 100% = incentive-compatible if the sponsor
is not a direct descendant of the sp= onsee.

Please see doc/policy/version3_transactions.md and
doc/pol= icy/packages.md in the PR for the full set of rules.

**Intended usag= e for LN:**

Commitment transactions should be V3 and have 1 anchor o= utput. 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 an= d
spend the anchor output in a high feerate transaction. I'm going t= o
call the broadcasted commitment tx "the parent" and the atta= ched
fee-bumping tx "the child."

- This child must be V= 3.
- This child must be at most 1000vB. Note this restricts the
=C2= =A0 number of inputs you can use to fund the fee bump. Depending
on the = output types, this is around 6-15.
- One child may fund fees for multipl= e commitment tx ("batched
=C2=A0 fee-bumping").
- To do a s= econd fee-bump to add more fees, replace the
=C2=A0 *child* with a highe= r-feerate tx. Do not try to attach a grandchild.

Otherwise, never tr= y to spend from an unconfirmed V3 transaction. The
descendant limits for= V3 transactions are very restrictive.

**Expected Questions:**
"Does this fix Rule 3 Pinning?"
Yes. The V3 descendant limit= restricts both you and your counterparty.
Assuming nodes adopted this p= olicy, you may reasonably assume that you
only need to replace the commi= tment transaction + up to 1000vB.

"Only 1 anchor output? What i= f I need to bump counterparty's commitment tx in mempool?"
You won't need to fee-bump a counterparty's commitment tx using CP= FP.
You would just package RBF it by attaching a high-feerate chi= ld to
your commitment tx.

"Is this a privacy issue, i.e. d= oesn't it allow fingerprinting LN
transactions based on nVersion?&qu= ot;
Indeed it may be unrealistic to assume V3 transactions will be inwidespread use outside of L2. IIUC, unilateral closes are already
obvio= us LN transactions because of the HTLC inputs. For e.g.
cooperative clos= es and opens, I think it makes sense to continue using
V2. So, unless I&= #39;m missing something, this shouldn't make it worse.

"So = a V3 transaction that doesn't signal BIP125 replaceability is
replac= eable? Is that a backward compatibility issue?"
Yes it's replac= eable. It's not an issue AFAICT because,
under previous policy, the = V3 transaction wouldn't have been
in the mempool in the first place.=

"Can a V2 transaction replace a V3 transaction and vice versa?= "
Yes, otherwise someone can use V3 transactions to censor V2
tr= ansactions spending shared inputs. Note if the
original V3 transaction h= as an unconfirmed V3 parent, this would
violate the "inherited V3&q= uot; rule and would be rejected.

Thanks for reading! Feedback and re= view would be much appreciated.

[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Septemb= er/019464.html

Best,
Gloria
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000075e2705e9d1e0c9--