Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BD81DC002D for ; Sat, 1 Oct 2022 10:00:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 9A2AF4199C for ; Sat, 1 Oct 2022 10:00:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9A2AF4199C Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=M7ElNwOn X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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 UFxj1GrU3k-i for ; Sat, 1 Oct 2022 10:00:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 243B841973 Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) by smtp4.osuosl.org (Postfix) with ESMTPS id 243B841973 for ; Sat, 1 Oct 2022 10:00:08 +0000 (UTC) Received: by mail-oo1-xc29.google.com with SMTP id z9-20020a4a4909000000b0047651b95fbdso3810408ooa.5 for ; Sat, 01 Oct 2022 03:00:08 -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=gKGii8lUorJ9iqX45DPvFZgWqf9r4q0UTGY5OSqKE2E=; b=M7ElNwOnmnJE1afpOei9SQYXmcX1nFUdJyLyLcPTeJXJX6ci1a07TgSjhk9c5ymwKk NPtwfaseYpGci73g42gujTaFUgJLMd0XArgZ+vwid2L4nrae90x+uY/56lRxGN278nat QMfZZmUD0sOqt9lwqbDt9rkmGyCtdqgQ/KsTSWRuTrAsOymjYNtiG0kXVfoo65AKD4Hh jOtdnrYoctBueaYtMWYn7gzo9sVjuYL/BZI/0ACvntWQXXpCnOyCJrPB+dc67sQboTKG xQdmpCpstkG6Z2z1opZmL0kZPkJj8xLKdVH8mOmJHaLRlwUUlnDw7EUjJKWPksM94kOD HKrg== 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=gKGii8lUorJ9iqX45DPvFZgWqf9r4q0UTGY5OSqKE2E=; b=RwsPOmvgSbr19IQxx89ehWrKC7JlJNlRMjqGQ2hD1GHwGa+3PStG4pn+qKmcgHDFHT eR15lLbt8zGCTc8RTozbchh9VK9tbCn+N9JRuGqUc9+XHR5i534IR/sLT5DKAp6e1avI BZlR7Q/XwUu6ut/E8POma/bOeCZYVGmDeEjfjjkJhCGBx0ZZMYx3Va6hM/O0+qXL5B+N 3vQgfRxjwLC4u010ZuhS6d2X+tAS761WmOtu3/1VS4Pt056MJHgh7yaN5Aha8NUXIJ1p ABI46b7WOR0IiM79OPpfzmOUwiBT7f/18iegv7bjZJHcWasVon7JTnRDw8ffjqKS9GRm Ez9A== X-Gm-Message-State: ACrzQf0G5E0XRsi1Gq0g3TD7DEBsPNecmcFrisMut9T1GLTRgJ6fQ2HI 1QpjlVO/2fZeEaA5JDRYOMA8VZ6Arr/VuIIMK0c= X-Google-Smtp-Source: AMsMyM46aqBo8gW7KQ/+Am9y44Oe/pfCZcivCd1lqEcvFMtF6RAcybIcJYGOrarttmeo15iLc/l9ul3Fd1M7daEEpvs= X-Received: by 2002:a4a:8932:0:b0:44b:3454:a9d3 with SMTP id f47-20020a4a8932000000b0044b3454a9d3mr4671579ooi.56.1664618406996; Sat, 01 Oct 2022 03:00:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ruben Somsen Date: Sat, 1 Oct 2022 11:59:55 +0200 Message-ID: To: Bastien TEINTURIER Content-Type: multipart/alternative; boundary="000000000000d5ef2205e9f62c34" X-Mailman-Approved-At: Sat, 01 Oct 2022 10:19:24 +0000 Cc: Bitcoin Protocol Discussion , Greg Sanders 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: Sat, 01 Oct 2022 10:00:12 -0000 --000000000000d5ef2205e9f62c34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bastien, >Greg already has a draft design that addresses your concerns Thanks, that is very nice. In that case I currently have no outstanding objections. >I'm curious why you would need more than one such output My reasoning was actually to allow only one OP_TRUE output per transaction, so I think we agree. Apologies if that wasn't clear. To summarize: 1. OP_TRUE output must be spent 2. Only one child allowed per transaction This ensures there is no scenario where a child is propagated that does not spend the OP_TRUE output. Cheers, Ruben On Fri, Sep 30, 2022 at 2:17 PM Greg Sanders wrote: > It's likely better if the ephemeral output can be any value, including > dust. This lets contract designers put "trimmed output" value indirectly > towards CPFP fees without making the parent tx have fees itself. > > On Fri, Sep 30, 2022, 8:08 AM Bastien TEINTURIER wrote= : > >> Hey Ruben, >> >> I discussed this further over IRC, and I now agree that this particular >> change would be very desirable and can likely fit in the initial release >> (even though I'm not the one writing that code, but I'd be happy to >> review it and test it). >> >> Greg already has a draft design that addresses your concerns: if there i= s >> an "ephemeral output" (0-value, OP_TRUE) in an unconfirmed v3 transactio= n, >> it MUST be spent by any child v3 transaction. This way, you ensure that >> any child transaction spending the unconfirmed parent spends the ephemer= al >> output(s). @Greg, correct me if I misunderstood something here. Note tha= t >> we will need to precisely define the criteria for those "ephemeral >> outputs" >> (it can probably simply be "outputs that are 0 sats"). >> >> Coupled with transactions that pay no fees (and thus require a child to >> CPFP in order to be included in a block), this ensures those outputs can >> never leak into the utxo set. How does that sound? >> >> I'm curious why you would need more than one such output, can you detail= ? >> I believe we only ever need one, spendable by anyone. >> >> Cheers, >> Bastien >> >> Le ven. 30 sept. 2022 =C3=A0 02:14, Ruben Somsen a = =C3=A9crit : >> >>> Hi Bastien, >>> >>> >The other change mentioned (making OP_TRUE standard and allowing outpu= ts >>> that are below dust) can be added later, as those won't be standard unt= il >>> we start allowing them, so there shouldn't be any backwards-compatibili= ty >>> issue with postponing this change. But maybe it's still worth having fr= om >>> the get-go, even though it may take a bit more time? Again, I'm curious >>> to >>> have other people's opinion here >>> >>> I'm sensitive to not wanting to overload the current discussion but thi= s >>> also interests me, provided it can be done in a way that is acceptable >>> (i.e. minimizing the potential UTXO set impact). It would solve a big c= ost >>> issue in my spacechains design if transactions could be 0 fees and have= a 0 >>> sat output that could be used in order to pay all the fees with CPFP. >>> >>> My current view is that a tx containing a single 0 sat OP_TRUE output >>> should only get relayed if it is a package where the OP_TRUE output is >>> currently being spent in a way that increases the overall fee rate. But >>> even then, one theoretical edge case remains: >>> - Another CPFP tx can feebump the package on a different (non-OP_TRUE) >>> output with an even higher fee rate >>> - Subsequently, the tx that is spending the OP_TRUE might fall out of >>> the mempool if the mempool fee rate rises >>> - This could cause the 0 sat output to enter the UTXO set (specifically= , >>> rational miners wouldn't refuse to mine such a tx) >>> >>> It doesn't seem like this would happen much in practice (nor is there a= n >>> incentive to do it on purpose), but the chance isn't 0. >>> >>> Cheers, >>> Ruben >>> >>> >>> >>> On Thu, Sep 29, 2022 at 4:50 PM Greg Sanders via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> > 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 HT= LCs! >>>> >>>> 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 wou= ld >>>>> make sense here is restricting the whole v3 package's size (instead o= f >>>>> just the child) via committing to a specific value in the taproot ann= ex >>>>> (also note that it's probably not just the v3 package's size, it shou= ld >>>>> 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 previousl= y >>>>> propagated wouldn't propagate under this new rule). As long as you ar= e >>>>> 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 to >>>>> have other people's opinion here, I'd be happy to get all of those >>>>> directly >>>>> 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 discussio= n >>>>>> around limitations as ideas for future improvements rather than crit= icisms >>>>>> of the proposal (please correct me if I'm wrong). I'll try to respon= d 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 cl= ose all >>>>>> pinning attacks possible (sorry for confusing anyone). I also agree = that >>>>>> some bits can be a little ugly or tack-on; I would definitely prefer= a >>>>>> comprehensive RBF revamp to fix all our problems and enable other >>>>>> fee-bumping strategies such as >>>>>> sign-ANYONECANPAY-then-bring-your-own-fees-by-adding-inputs-at-broad= cast. I >>>>>> was hoping to get some ideas with the "RBF Improvements" post in Jan= uary, >>>>>> but it doesn't seem like we're much closer to a workable proposal. I= think >>>>>> this is a minimally-invasive step that works for Lightning today, a = small >>>>>> 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 th= e >>>>>> parent 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. >>>>>> >>>>>> (For more context to other readers I wrote an explanation for this i= n >>>>>> "SIGHASH_ANYONECANPAY Pinning" section of RBF ML post). Yes, this >>>>>> unfortunately doesn't fix any of the existing pinning attacks for si= ngle >>>>>> transaction RBF but also doesn't make them worse. This boils down to= adding >>>>>> 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 >>>>>> is lower than the feerate of what is being replaced. But it is imper= fect >>>>>> (explained below) and thus I wouldn't recommend it for single transa= ction >>>>>> replacement. So that attack still exists for single transactions, ye= s. >>>>>> >>>>>> 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 not affected by this since it doesn't use ACP, though obv= iously >>>>>> 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 output= s." >>>>>> 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 o= thers. >>>>>> Now you must pay higher rates to replace all of the transaction bump= s. 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-feerat= e >>>>>> 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 al= l to >>>>>> the highest target feerate." Isn't this kind of separate, wallet-rel= ated >>>>>> problem? Contracting or not, surely every wallet needs to have enoug= h UTXOs >>>>>> to not batch transactions that shouldn't be batched... I don't see h= ow a >>>>>> replace-by-ancestor-feerate policy would make any difference for thi= s? >>>>>> >>>>>> Also in general I'd like to reiterate that ancestor feerate is not a >>>>>> panacea to all our RBF incentive compatibility concerns. Like indivi= dual >>>>>> feerate, unless we run the mining algorithm, it cannot tell us exact= ly how >>>>>> 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 = letting >>>>>> 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 orig= inal >>>>>> transactions are. This rule "The minimum between package feerate and >>>>>> ancestor feerate of the child is not lower than the individual feera= tes of >>>>>> all directly conflicting transactions and the ancestor feerates of a= ll >>>>>> original transactions" is a conservative estimate. >>>>>> >>>>>> > Would kind of be nice if package RBF would detect a "sibling outpu= t >>>>>> spend" conflict, and knock it out of the mempool via the other repla= cement >>>>>> rules? Getting rid of the requirement to 1 block csv lock every outp= ut >>>>>> 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 be= tter >>>>>> mining candidates. As in, if we added this policy and it can make us= evict >>>>>> the sibling and accept a transaction with a bunch of low-feerate anc= estor >>>>>> junk, it would be a new pinning vector. >>>>>> >>>>>> > If you're a miner and you receive a non-V3, second descendant of a= n >>>>>> unconfirmed V3 transaction, if the offered fee is in the top mempool >>>>>> backlog, I think you would have an interest to accept such a transac= tion. >>>>>> >>>>>> > 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 i= t, but >>>>>> 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 D= oS >>>>>> protection, while this 1-descendant limit rule is more of a "help th= e >>>>>> 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 do >>>>>> think it's worth it. >>>>>> >>>>>> > > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot b= e >>>>>> >>>>>> > > 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 >>>>>> child due to the limited size, if they would like this transaction t= o 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 *d= on't* >>>>>> want this tx to confirm, normally, this child would be really large.= If >>>>>> they only have 1000vB for the child, they can't increase the replace= ment >>>>>> cost without also fee-bumping the transaction to make it confirm fas= ter. >>>>>> >>>>>> > As of today, I think yes you can already fingerprint LN >>>>>> transactions on the spec-defined amount value of the anchor outputs= , 330 >>>>>> sats. There is always one of them on post-anchor commitment transact= ions. >>>>>> 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 th= e >>>>>>> ParentTx based on what is in the mempool, then look at the "rest" o= f the >>>>>>> transactions as a package, then individually. Not the same, not sur= e 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 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 spendabl= e >>>>>>>> by >>>>>>>> both participants (or even anyone), so if you see your >>>>>>>> counterparty's >>>>>>>> commitment in your mempool, you can bump it without publishing you= r >>>>>>>> own commitment, which is quite desirable (your own commitment tx h= as >>>>>>>> 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 L= N >>>>>>>> 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 >>>>>>>> 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 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. N= o >>>>>>>> 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, if 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 >>>>>>>> probably >>>>>>>> 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 m= empool >>>>>>>>> backlog, I think you would have an interest to accept such a tran= saction. >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> child due to the limited size, if they would like this transactio= n to be >>>>>>>>> stuck in the network mempools. By doing so this child has high o= dds to >>>>>>>>> confirm. >>>>>>>>> >>>>>>>>> I still wonder if this compatible with miner incentives in period >>>>>>>>> of empty mempools, in the sense that if you've already a V3 trans= action of >>>>>>>>> size 100Kvb offering 2 sat/vb, it's more interesting than a V3 re= placement >>>>>>>>> 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-feer= ate child >>>>>>>>> *latter* making for a utxo considered the best ancestor set. Mayb= e in the >>>>>>>>> long-term miners should keep every transaction ever accepted...) >>>>>>>>> >>>>>>>>> > (Lower bound) 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 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 counte= rparty >>>>>>>>> could enter in a "cat-and-mouse" game to replace one of the batch= element >>>>>>>>> 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. L= N >>>>>>>>> wallets are likely to have one big UTXO in their fee-bumping rese= rve pool, >>>>>>>>> as the cost of acquiring UTXO is non-null and in the optimistic c= ase, you >>>>>>>>> don't need to do unilateral closure. Let's say you close dozens o= f 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 feed the remaini= ng >>>>>>>>> in-flight channels. >>>>>>>>> >>>>>>>>> > 1. The rule around unconfirmed inputs was >>>>>>>>> > originally "A package may include new unconfirmed inputs, but t= he >>>>>>>>> > 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, w= here a >>>>>>>>> counterparty pins a HTLC-preimage by abusing rule 3. In that case= , the >>>>>>>>> honest LN node should be able to broadcast a "at least as high an= cestor >>>>>>>>> feerate" HTLC-timeout transaction. With `option_anchor_outputs" t= here is no >>>>>>>>> unconfirmed ancestor to replace, as the commitment transaction, w= hatever >>>>>>>>> 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 outp= uts, 330 >>>>>>>>> sats. There is always one of them on post-anchor commitment trans= actions. >>>>>>>>> And sadly I would say we'll always have tricky fingerprints leaki= ng from >>>>>>>>> unilateral 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 o= f >>>>>>>>> the new package RBF rules applied. I think this would be a signif= icant >>>>>>>>> advantage for LN, as for the current ~85k of opened channels, the= old V2 >>>>>>>>> states shouldn't be pinning vectors. Currently, commitment transa= ctions >>>>>>>>> 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 >>>>>>>>>> relay >>>>>>>>>> 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 >>>>>>>>>> Towns, and others.) >>>>>>>>>> >>>>>>>>>> If you are interested in using package RBF/relay to bump presign= ed >>>>>>>>>> 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, i= f >>>>>>>>>> you 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 was >>>>>>>>>> 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 k= now >>>>>>>>>> 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 addition= al >>>>>>>>>> rules apply to V3: >>>>>>>>>> >>>>>>>>>> 1. A V3 transaction can be replaced, even if it does not signal >>>>>>>>>> BIP125 >>>>>>>>>> replaceability. (It must also meet the other RBF rules around >>>>>>>>>> fees, >>>>>>>>>> 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 >>>>>>>>>> transaction >>>>>>>>>> signals replaceability this way does not require mempool >>>>>>>>>> traversal, >>>>>>>>>> and does not change based on what transactions are mined. It als= o >>>>>>>>>> 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 presigne= d >>>>>>>>>> transactions paying 0 fees and 1 output for attaching a CPFP at >>>>>>>>>> broadcast time ("anchor output"). Without package RBF, multiple >>>>>>>>>> anchor >>>>>>>>>> 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 b= e >>>>>>>>>> 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 >>>>>>>>>> child >>>>>>>>>> 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 ma= y >>>>>>>>>> use >>>>>>>>>> to fund this fee-bump. For example, only allowing the V3 child t= o >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> 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. With 1000 virtu= al >>>>>>>>>> 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 its >>>>>>>>>> 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, eve= n >>>>>>>>>> if >>>>>>>>>> the policy is 10KvB. >>>>>>>>>> >>>>>>>>>> **Package RBF modifications:** >>>>>>>>>> >>>>>>>>>> 1. The rule around unconfirmed inputs was >>>>>>>>>> originally "A package may include new unconfirmed inputs, but th= e >>>>>>>>>> ancestor feerate of the child must be at least as high as the >>>>>>>>>> ancestor >>>>>>>>>> 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 individu= al >>>>>>>>>> feerates of all directly conflicting transactions and the ancest= or >>>>>>>>>> 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 >>>>>>>>>> representative >>>>>>>>>> of its incentive compatibility; it may overestimate (some subset >>>>>>>>>> of >>>>>>>>>> the ancestors could be included by itself if it has other >>>>>>>>>> high-feerate >>>>>>>>>> descendants or are themselves higher feerate than this >>>>>>>>>> package/transaction). Instead, we use the 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 >>>>>>>>>> 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 difficu= lt >>>>>>>>>> to account for all of the possibilities. For example, it gets mu= ch >>>>>>>>>> harder to see that we're applying the descendant limits correctl= y >>>>>>>>>> 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 mu= st >>>>>>>>>> be broadcast, determine the desired feerate at broadcast time an= d >>>>>>>>>> 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 >>>>>>>>>> grandchild. >>>>>>>>>> >>>>>>>>>> Otherwise, never try 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 policy, you may reasonably assume >>>>>>>>>> that you >>>>>>>>>> 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 L= N >>>>>>>>>> transactions based on nVersion?" >>>>>>>>>> Indeed it may be unrealistic to assume V3 transactions will be i= n >>>>>>>>>> widespread use outside of L2. IIUC, unilateral closes are alread= y >>>>>>>>>> obvious LN transactions because of the HTLC inputs. For e.g. >>>>>>>>>> cooperative closes and opens, I think it makes sense to continue >>>>>>>>>> using >>>>>>>>>> V2. So, unless I'm missing something, this shouldn't make it >>>>>>>>>> worse. >>>>>>>>>> >>>>>>>>>> "So a V3 transaction that doesn't signal BIP125 replaceability i= s >>>>>>>>>> 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 appreciate= d. >>>>>>>>>> >>>>>>>>>> [1]: >>>>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Sep= tember/019464.html >>>>>>>>>> [2]: >>>>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Jan= uary/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 >>>>>>>> >>>>>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> --000000000000d5ef2205e9f62c34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bastien,

>Greg already has a draf= t design that addresses your concerns

Thanks, that= is very nice. In that case I currently have no outstanding objections.

>I'm curious why you would need more than one = such output

My reasoning was actually to allow onl= y one OP_TRUE output per transaction, so I think we agree. Apologies if tha= t wasn't clear.

To summarize:

1. OP_TRUE output must be spent
2. Only one child allowe= d per transaction

This ensures there is no scenari= o where a child is propagated that does not spend the OP_TRUE output.
=

Cheers,
Ruben

On Fri, Sep 30, 2022 at 2:= 17 PM Greg Sanders <gsanders87@g= mail.com> wrote:
It's likely better if the ephemeral output ca= n be any value, including dust. This lets contract designers put "trim= med output" value indirectly towards CPFP fees without making the pare= nt tx have fees itself.=C2=A0

On Fri, Sep 30, 2022, 8:08 AM Bastien TEINTUR= IER <bastien@acinq= .fr> wrote:
Hey Ruben,

I discussed this further over IRC, an= d I now agree that this particular
change would be very desirable and ca= n likely fit in the initial release
(even though I'm not the one wr= iting that code, but I'd be happy to
review it and test it).

Greg already has a draft design that addresses your concerns: if the= re is
an "ephemeral output" (0-value, OP_TRUE) in an unconfirm= ed v3 transaction,
it MUST be spent by any child v3 transaction. This wa= y, you ensure that
any child transaction spending the unconfirmed parent= spends the ephemeral
output(s). @Greg, correct me if I misunderstood so= mething here. Note that
we will need to precisely define the criteria fo= r those "ephemeral outputs"
(it can probably simply be "o= utputs that are 0 sats").

Coupled with transactions that pay no= fees (and thus require a child to
CPFP in order to be included in a blo= ck), this ensures those outputs can
never leak into the utxo set. How do= es that sound?

I'm curious why you would need more than one such= output, can you detail?
I believe we only ever need one, spendable by a= nyone.

Cheers,
Bastien

=
Le=C2=A0ven. 30 sept. 2022 =C3=A0=C2= =A002:14, Ruben Somsen <rsomsen@gmail.com> a =C3=A9crit=C2=A0:
=
Hi Bastien,

>The other change mentioned (making O= P_TRUE standard and allowing outputs
that are below dust) can be added l= ater, as those won't be standard until
we start allowing them, so th= ere shouldn't be any backwards-compatibility
issue with postponing t= his 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 to
have other= people's opinion here

I'm sensitive to not want= ing to overload the current discussion but this also interests me, provided= it can be done in a way that is acceptable (i.e. minimizing the potential = UTXO set impact). It would solve a big cost issue in my spacechains design = if transactions could be 0 fees and have a 0 sat output that could be used = in order to pay all the fees with CPFP.

My current= view is that a tx containing a single 0 sat OP_TRUE output should only get= relayed if it is a package where the OP_TRUE output is currently being spe= nt in a way that increases the overall fee rate. But even then, one theoret= ical edge case remains:
- Another CPFP tx can feebump the pac= kage on a different (non-OP_TRUE) output with an even higher fee rate
=
- Subsequently, the tx that is spending the OP_TRUE might fall out of = the mempool if the mempool fee rate rises
- This could cause the = 0 sat output to enter the UTXO set (specifically, rational miners wouldn= 9;t refuse to mine such a tx)

It doesn't seem = like this would happen much in practice (nor is there an incentive to do it= on purpose), but the chance isn't 0.

Cheers,<= /div>
Ruben



On Thu, Sep 2= 9, 2022 at 4:50 PM Greg Sanders via bitcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
> Right, good catch, t= his does require new logic to handle this case.
As Gloria points out, th= is should be doable, and is definitely worth
adding (those CSV 1 on ever= y other output are really hacky, glad to
find a way to get rid of them).=

For the record, it turns out ephemeral anchors=C2=A0+ v= 3 solves this already, as the anchor must be spent, and the parent tx may o= nly have one child. Somehow I missed this implication for a few months. It&= #39;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 &l= t;= bastien@acinq.fr> wrote:
Hi Gloria, Greg,

> I interpret m= ost of the discussion around limitations as ideas for
> future improv= ements rather than criticisms of the proposal

As far as I'm conc= erned, definitely!

My current understanding is that the main change/= improvement that would
make sense here is restricting the whole v3 packa= ge's size (instead of
just the child) via committing to a specific v= alue in the taproot annex
(also note that it's probably not just the= v3 package's size, it should
be the whole unconfirmed package inclu= ding potential v2 unconfirmed
ancestors).

While I think this woul= d 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 s= tricter (some v3 transactions that previously
propagated wouldn't pr= opagate 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 b= e able to resolve ACP pinning issues?

I'm curious to know how ot= her people feel about that: is it ok to do
later or should we try to imp= lement this for the first release of v3
transactions?

The other c= hange mentioned (making OP_TRUE standard and allowing outputs
that are b= elow dust) can be added later, as those won't be standard until
we s= tart allowing them, so there shouldn't be any backwards-compatibilityissue 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 to
have other people's opinion here, I'd be happy to ge= t all of those directly
in the first release of v3 transactions, but I d= on't know how much
implementation will have to go into that.

= > For clarification, package RBF is ParentTx*s*(plural), and ChildTx(sin= gular),
> so it might be a bit more complicated than we're thinki= ng

Right, good catch, this does require new logic to handle this cas= e.
As Gloria points out, this should be doable, and is definitely worth<= br>adding (those CSV 1 on every other output are really hacky, glad to
f= ind a way to get rid of them).

Thanks,
Bastien

Le=C2=A0lun. 26 sep= t. 2022 =C3=A0=C2=A018:48, Gloria Zhao <gloriajzhao@gmail.com>= a =C3=A9crit=C2=A0:
Hi Greg, Antoine, Bastien, =C2=A0
=C2=A0
Thank= s very much for the feedback! I interpret most of the discussion around lim= itations as ideas for future improvements rather than criticisms of the pro= posal (please correct me if I'm wrong). I'll try to respond to as m= uch 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 pinning attacks possible (sorry for confusing anyone= ). I also agree that some bits can be a little ugly or tack-on; I would def= initely prefer a comprehensive RBF revamp to fix all our problems and enabl= e other fee-bumping strategies such as sign-ANYONECANPAY-then-bring-your-ow= n-fees-by-adding-inputs-at-broadcast. I was hoping to get some ideas with t= he "RBF Improvements" post in January, but it doesn't seem li= ke we're much closer to a workable proposal. I think this is a minimall= y-invasive step that works for Lightning today, a small fix similar to CPFP= carve out.

> As you likely know from previous discussions the bi= ggest scenario this does not fix in my estimation is ANYONECANPAY situation= s. If the parent transaction can be "inflated" by tacking on addi= tional inputs, this means the total weight of the parent tx lowers the effe= ctive feerate of the package. =C2=A0
=C2=A0
(For more context to oth= er readers I wrote an explanation for this in "SIGHASH_ANYONECANPAY Pi= nning" section of RBF ML post).=C2=A0 Yes, this unfortunately doesn= 9;t fix any of the existing pinning attacks for single transaction RBF but = also doesn't make them worse. This boils down to adding an incentive co= mpatibility rule that ensures you can't replace a transaction with some= thing that will confirm slower. Package RBF has an ancestor feerate-based r= ule 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 is= lower than the feerate of what is being replaced. But it is imperfect (exp= lained below) and thus I wouldn't recommend it for single transaction r= eplacement. So that attack still exists for single transactions, yes. =C2= =A0

The strategy of using ACP to bring-your-own-fees has its own cha= llenges but hopefully has no current use cases as you say. AFAIK LN Penalty= is not affected by this since it doesn't use ACP, though obviously I a= gree we should fix it for the future.

So when I said "this is i= ntended for fee-bumping presigned txns in contracting protocols," I sh= ould have said "this is intended for fee-bumping presigned txns specif= ically using CPFP and anchor outputs." Apologies for forgetting to con= textualize, I've been sitting on this for too long.
=C2=A0
> = 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 constr= aints, you may want to accelerate some and not others. Now you must pay hig= her rates to replace all of the transaction bumps. This is a "self-pin= " and "get good at utxos noob" type problem, but it's so= mething that axing 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 do= n'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." Is= n't this kind of separate, wallet-related problem? Contracting or not, = surely every wallet needs to have enough UTXOs to not batch transactions th= at shouldn't be batched... I don't see how a replace-by-ancestor-fe= erate policy would make any difference for this?

Also in general I&#= 39;d like to reiterate that ancestor feerate is not a panacea to all our RB= F incentive compatibility concerns. Like individual feerate, unless we run = the mining algorithm, it cannot tell us exactly how quickly this transactio= n would be mined.

We're estimating the incentive compatibility o= f the original transaction(s) and replacement transaction(s), with the goal= of not letting a transaction replace something that would have been more i= ncentive 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 t= he original transactions are. This rule "The minimum between package f= eerate and ancestor feerate of the child is not lower than the individual f= eerates 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 sp= end" 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 w= ould 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 transac= tion, 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 r= eplacements to be better mining candidates. As in, if we added this policy = and it can make 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 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. = =C2=A0 =C2=A0 =C2=A0
> So I'm not sure if those two rules are com= patible with miners incentives... =C2=A0
=C2=A0
The same argument ca= n be made for the 26th descendant of a mempool transaction; it's also n= ot entirely incentive-compatible to reject it, but that is not the *only* d= esign goal in mempool policy. Of course, the difference here is that the 25= -descendant limit rule is a sensible DoS protection, while this 1-descendan= t limit rule is more of a "help the Bitcoin ecosystem" policy, ju= st like CPFP carve-out, dust limit, etc. I can of course understand why not= everyone would be in favor of this, but I do think it's worth it.
= =C2=A0
> > 4. A V3 transaction that has an unconfirmed V3 ancesto= r cannot be =C2=A0 =C2=A0
> > =C2=A0 =C2=A0larger than 1000 virtua= l bytes. =C2=A0 =C2=A0
=C2=A0 =C2=A0
> If I understand correctly t= he 1000 vb upper bound rational, it would be to constraint the pinning coun= terparty to attach a high fee to a child due to the limited size, if they w= ould like this transaction to be stuck in the network mempools. By doing so= =C2=A0 this child has high odds to confirm. =C2=A0
=C2=A0
Yeah = exactly, the "Rule 3 pin" is done by adding a child that's hi= gh-fee (so you have to pay that much to evict it). Because they *don't*= want this tx to confirm, normally, this child would be really large. If th= ey only have 1000vB for the child, they can't increase the replacement = cost without also fee-bumping the transaction to make it confirm faster.=C2= =A0

> 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 transaction= s. And sadly I would say we'll always have tricky fingerprints leaking = from unilateral LN closures such as HTLC/PTLC timelocks... =C2=A0
<= br>
> I agree with you, this isn't worse than today, unila= teral closes will
probably always be identifiable on-chain.
=
Great to hear that there is no privacy worsening!

Best, =C2=A0Gloria

On Mon, Sep 26, 2022 at 5:02 PM Greg Sanders <gsanders87@g= mail.com> wrote:
Bastien,

> This may be alrea= dy covered by the current package RBF logic, in that
scenario we are s= imply replacing [ParentTx, ChildTx1] with
[ParentTx, ChildTx2] that pays= more fees, right?

For clarification, package RBF is Par= entTx*s*(plural), and ChildTx(singular), so it might be a bit more complica= ted than we're thinking, and currently the V3 proposal would first de-d= uplicate=C2=A0the ParentTx based on what is in the mempool, then look at th= e "rest" of the transactions 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 Bast= ien TEINTURIER via bitcoin-dev <bitcoin-dev@lists.lin= uxfoundation.org> wrote:
Thanks Gloria for this great post.

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

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

Note that we can also very easily make that s= ingle 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 o= wn commitment tx has
CSV delays on your outputs, whereas your counterpar= ty's commitment tx
doesn't).

> "Is this a privacy= issue, i.e. doesn't it allow fingerprinting LN
transactions based o= n 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 out= put spend"
> conflict, and knock it out of the mempool via the o= ther replacement rules?
> Getting rid of the requirement to 1 block c= sv lock every output would be
> quite nice from a smart contracting c= omposability point of view.

+1, that would be very neat!

This= may be already covered by the current package RBF logic, in that
scenar= io we are simply replacing [ParentTx, ChildTx1] with
[ParentTx, ChildTx2= ] that pays more fees, right?

> 1) I do think that we should seri= ously 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
&= gt; anchor to a specific wallet/user. We can save quite a few bytes by havi= ng
> 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 th= e 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 p= arent transaction is
> dropped if the child spend is dropped, but may= be it's worth the squeeze.

I also think both of these could be q= uite useful. This would probably always
be used in combination with a pa= rent 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-valu= e outputs in the utxo set, if for
some reason the parent tx is CPFP-ed v= ia another output than the 0-value one,
which would be a utxo set bloat = issue. But I'd argue that we're probably
already creating utxo s= et 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=C2=A0lun. 26 s= ept. 2022 =C3=A0=C2=A003:22, Antoine Riard via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
H= i Gloria,

Thanks for the progress on package RBF, few early question= s.

> 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 tr= ansaction.

So I'm not sure if those two rules are compatible wit= h miners incentives...

> 4. A V3 transaction that has an unconfir= med V3 ancestor cannot be
> =C2=A0 =C2=A0larger than 1000 virtual byt= es.

If I understand correctly the 1000 vb upper bound rational, it w= ould be to constraint the pinning counterparty to attach a high fee to a ch= ild due to the limited size, if they would like this transaction to be stuc= k in the network mempools. By doing so=C2=A0 this child has high odds to co= nfirm.

I still wonder if this compatible with miner incentives in pe= riod of empty mempools, in the sense that if you've already a V3 transa= ction of size 100Kvb offering 2 sat/vb, it's more interesting than a V3= replacement candidate of size 1000 vb offering 10 sat/vb. It could be argu= ed the former should be conserved.

(That said, the hard thing with a= ny 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 transact= ion ever accepted...)

> (Lower bound) the smaller this limit, the= fewer UTXOs a child may use
> to fund this fee-bump. For example, on= ly allowing the V3 child to have
> 2 inputs would require L2 protocol= s to manage a wallet with high-value
> UTXOs and make batched fee-bum= ping impossible. However, as the
> fee-bumping child only needs to fu= nd fees (as opposed to payments),
> just a few UTXOs should suffice.<= br>
Reminder for L2 devs, batched fee-bumping of time-sensitive confirma= tions of commitment transactions is unsafe, as the counterparty could enter= in a "cat-and-mouse" game to replace one of the batch element 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 res= erve 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 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 feed the= remaining in-flight channels.

> 1. The rule around unconfirmed i= nputs was
> originally "A package may include new unconfirmed in= puts, but the
> ancestor feerate of the child must be at least as hig= h as the ancestor
> feerates of every transaction being replaced.&quo= t;

Note, I think we would like this new RBF rule to also apply to si= ngle transaction package, e.g second-stage HTLC transactions, where a count= erparty pins a HTLC-preimage by abusing rule 3. In that case, the honest LN= node should be able to broadcast a "at least as high ancestor feerate= " HTLC-timeout transaction. With `option_anchor_outputs" there is= no unconfirmed ancestor to replace, as the commitment transaction, whateve= r the party it is originating from, should already be confirmed.

>= ; "Is this a privacy issue, i.e. doesn't it allow fingerprinting L= N
transactions based on nVersion?"

As of today, I think yes = you can already fingerprint LN transactions on the=C2=A0 spec-defined amoun= t value of the anchor outputs, 330 sats. There is always one of them on pos= t-anchor commitment transactions. And sadly I would say we'll always ha= ve tricky fingerprints leaking from unilateral LN closures such as HTLC/PTL= C timelocks...

> "Can a V2 transaction replace a V3 transact= ion and vice versa?"

IIUC, a V3 package could replace a V2 pack= age, with the benefit of the new package RBF rules applied. I think this wo= uld be a significant advantage for LN, as for the current ~85k of opened ch= annels, the old V2 states shouldn't be pinning vectors. Currently, comm= itment transactions signal replaceability.

Le=C2=A0ven. 23 sept. 2022 = =C3=A0=C2=A011:26, Gloria Zhao via bitcoin-dev <bitco= in-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
Hi everyone,<= br>
I'm writing to propose a very simple set of mempool/transaction = relay
policies intended to aid L2/contract protocols. I realized thatthe previously proposed Package Mempool Accept package RBF [1]
had= a few remaining problems after digging into the RBF logic more [2].
<= div>This additional set of policies solves them without requiring a huge RB= F overhaul.

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

(You may notice that this proposal incorporates feedback= on the PR - thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Ant= hony Towns, and others.)

If you are interested in using package RBF/= relay to bump presigned
transactions, I think you may be interested in r= eviewing this proposal.
This should solve Rule 3 pinning and perhaps all= ow us
to get rid of CPFP carve-out (yay!). I'm keen to hear if peopl= e find
the 1-anchor-output, 1000vB child limit too restrictive. Also, if= you find a
pinning attack or something that makes it unusable for you, = I would
really really like to know.

Note that transactions with n= Version=3D3 ("V3 transactions") are
currently non-standard in = Bitcoin Core. That means **anything that was
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&#= 39;re doing and don't use
nVersion=3D3. AFAICT this shouldn't br= eak anything, but let me know if
this would be disruptive for you?
**New Policies:**

This includes:
- a set of additional policy r= ules 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 fol= lowing additional
rules apply to V3:

1. A V3 transaction can be r= eplaced, even if it does not signal BIP125
=C2=A0 =C2=A0replaceability. = (It must also meet the other RBF rules around fees,
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 pr= operty of
"inherited" replaceability signaling when descendant= s of unconfirmed
transactions are created. Additionally, checking whethe= r a transaction
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 chec= k.

*Note*: The descendant of a *confirmed* V3 transaction does not n= eed 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 problema= tic pinning
attack, i.e., a malicious counterparty prevents the transact= ion from
being replaced by adding many descendant transactions that aren= 't
fee-bumping.

(Lower bound) at least 1 descendant is requir= ed 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 RB= F, multiple anchor
outputs would be required to allow each counterparty = to fee-bump any
presigned transaction. With package RBF, since the presi= gned
transactions can replace each other, 1 anchor output is sufficient.=

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

*Rationale*: (Upper b= ound) the larger the descendant size limit, the
more vbytes may need to = be replaced. With default limits, if the child
is e.g. 100,000vB, that m= ight 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 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 wit= h high-value
UTXOs and make batched fee-bumping impossible. However, as = the
fee-bumping child only needs to fund fees (as opposed to payments),<= br>just a few UTXOs should suffice.

With a limit of 1000 virtual byt= es, 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-manage= d UTXO pool. With 1000 virtual
bytes as the descendant limit, the cost t= o 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 its
own (`M= AX_STANDARD_TX_WEIGHT`) and 101KvB with descendants
(`DEFAULT_DESCENDANT= _SIZE_LIMIT_KVB`). If an existing V3 transaction
in the mempool is 100Kv= B, its descendant can only be 1000vB, even if
the policy is 10KvB.
**Package RBF modifications:**

1. The rule around unconfirmed inpu= ts was
originally "A package may include new unconfirmed inputs, bu= t the
ancestor feerate of the child must be at least as high as the ance= stor
feerates of every transaction being replaced."

The pack= age may still include new unconfirmed inputs. However,
the new rule is m= odified to be "The minimum between package feerate
and ancestor fee= rate of the child is not lower than the individual
feerates of all direc= tly conflicting transactions and the ancestor
feerates of all original t= ransactions."

*Rationale*: We are attempting to ensure that the= replacement
transactions are not less incentive-compatible to mine. How= ever, a
package/transaction's ancestor feerate is not perfectly repr= esentative
of its incentive compatibility; it may overestimate (some sub= set of
the ancestors could be included by itself if it has other high-fe= erate
descendants or are themselves higher feerate than this
package/= transaction). Instead, we use the minimum between the package
feerate an= d ancestor feerate of the child as a more conservative value
than what w= as proposed originally.

2. A new rule is added, requiring that all p= ackage transactions with
mempool conflicts to be V3. This also means the= "sponsoring"
child transaction must be V3.

*Note*: Com= bined with the V3 rules, this means the package must be
a child-with-par= ents package. Since package validation is only
attempted if the transact= ions do not pay sufficient fees to be
accepted on their own, this effect= ively 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 economic= ally 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<= br>to account for all of the possibilities. For example, it gets much
ha= rder to see that we're applying the descendant limits correctly if
t= he package has a gnarly, many-generation, non-tree shape. I'm also
n= ot sure if this policy is 100% incentive-compatible if the sponsor
is no= t 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 o= f rules.

**Intended usage for LN:**

Commitment transactions s= hould 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 desir= ed feerate at broadcast time and
spend the anchor output in a high feera= te transaction. I'm going to
call the broadcasted commitment tx &quo= t;the parent" and the attached
fee-bumping tx "the child."= ;

- This child must be V3.
- This child must be at most 1000vB. N= ote this restricts the
=C2=A0 number of inputs you can use to fund the f= ee bump. Depending
on the output types, this is around 6-15.
- One ch= ild may fund fees for multiple commitment tx ("batched
=C2=A0 fee-b= umping").
- To do a second fee-bump to add more fees, replace the=C2=A0 *child* with a higher-feerate tx. Do not try to attach a grandchil= d.

Otherwise, never try 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 policy, you may reasonably assume that you
o= nly 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
trans= actions based on nVersion?"
Indeed it may be unrealistic to assume = V3 transactions will be in
widespread use outside of L2. IIUC, unilatera= l closes are already
obvious LN transactions because of the HTLC inputs.= For e.g.
cooperative closes and opens, I think it makes sense to contin= ue using
V2. So, unless I'm missing something, this shouldn't ma= ke it worse.

"So a V3 transaction that doesn't signal BIP12= 5 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 th= e mempool in the first place.

"Can a V2 transaction replace a V= 3 transaction and vice versa?"
Yes, otherwise someone can use V3 tr= ansactions to censor V2
transactions spending shared inputs. Note if the=
original V3 transaction has an unconfirmed V3 parent, this would
vio= late the "inherited V3" rule and would be rejected.

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

[1]: https://lists.linuxf= oundation.org/pipermail/bitcoin-dev/2021-September/019464.html
=

Best,
Gloria
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000d5ef2205e9f62c34--