path: root/4e/40275e1b1d87e0db1c38a55fcf55608118aa2e

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 18E50C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 29 Sep 2022 14:41:40 +0000 (UTC)
Received: by mail-pg1-x52f.google.com with SMTP id s26so1632431pgv.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAFXO6=KDys2_dsrdxE9_q_MVZJOFMbg-MctxiokcicP=wd4Lkw@mail.gmail.com>
 <CALZpt+HYUti=foo+d5ER7Wj=PxsfgaU2CEqqG4_KRxmsWoaSxw@mail.gmail.com>
 <CACdvm3PyP9yrxx_Yewtx_yQh=i2uwGYj-wtY7HBER1bmG46NEw@mail.gmail.com>
 <CAB3F3Du=+YYKbfgB5LZPnCg40=5YCn_0tkpJ4LO9bMK0U-3wXg@mail.gmail.com>
 <CAFXO6=JGBPVpxTJnSMWCCZVPHZW_RyWQ2Cv18Ao_F=uQx3LVkg@mail.gmail.com>
 <CACdvm3OUpODbMzkcG+=qYzR9myrvSp-LpuGmETow94JavU2GDw@mail.gmail.com>
In-Reply-To: <CACdvm3OUpODbMzkcG+=qYzR9myrvSp-LpuGmETow94JavU2GDw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 29 Sep 2022 10:41:28 -0400
Message-ID: <CAB3F3DvCw9Ms+HUMaFnqV0P-Oo+rfERY+j5S5CC_X2NKRd5u8g@mail.gmail.com>
To: Bastien TEINTURIER <bastien@acinq.fr>
Content-Type: multipart/alternative; boundary="000000000000075e2705e9d1e0c9"
X-Mailman-Approved-At: Thu, 29 Sep 2022 14:50:28 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bastien@acinq.fr> 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 <gloriajzhao@gmail.com> 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 <gsanders87@gmail.com>
>> 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

<div dir=3D"ltr">&gt; Right, good catch, this does require new logic to han=
dle this case.<br>As Gloria points out, this should be doable, and is defin=
itely worth<br>adding (those CSV 1 on every other output are really hacky, =
glad to<br>find a way to get rid of them).<div><br></div><div>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&#39;s great news if we can direct=
ly source fees from any output claimable, including HTLCs!</div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep=
 29, 2022 at 5:15 AM Bastien TEINTURIER &lt;<a href=3D"mailto:bastien@acinq=
.fr">bastien@acinq.fr</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr">Hi Gloria, Greg,<br><br>&gt; I interp=
ret most of the discussion around limitations as ideas for<br>&gt; future i=
mprovements rather than criticisms of the proposal<br><br>As far as I&#39;m=
 concerned, definitely!<br><br>My current understanding is that the main ch=
ange/improvement that would<br>make sense here is restricting the whole v3 =
package&#39;s size (instead of<br>just the child) via committing to a speci=
fic value in the taproot annex<br>(also note that it&#39;s probably not jus=
t the v3 package&#39;s size, it should<br>be the whole unconfirmed package =
including potential v2 unconfirmed<br>ancestors).<br><br>While I think this=
 would be very valuable and would like to see this<br>happen, I believe tha=
t can be done in a second, separate step since this<br>would make relay pol=
icy stricter (some v3 transactions that previously<br>propagated wouldn&#39=
;t propagate under this new rule). As long as you are<br>able to find a pat=
h to miners through upgraded peers that use this annex<br>approach, you sho=
uld be able to resolve ACP pinning issues?<br><br>I&#39;m curious to know h=
ow other people feel about that: is it ok to do<br>later or should we try t=
o implement this for the first release of v3<br>transactions?<br><br>The ot=
her change mentioned (making OP_TRUE standard and allowing outputs<br>that =
are below dust) can be added later, as those won&#39;t be standard until<br=
>we start allowing them, so there shouldn&#39;t be any backwards-compatibil=
ity<br>issue with postponing this change. But maybe it&#39;s still worth ha=
ving from<br>the get-go, even though it may take a bit more time? Again, I&=
#39;m curious to<br>have other people&#39;s opinion here, I&#39;d be happy =
to get all of those directly<br>in the first release of v3 transactions, bu=
t I don&#39;t know how much<br>implementation will have to go into that.<br=
><br>&gt; For clarification, package RBF is ParentTx*s*(plural), and ChildT=
x(singular),<br>&gt; so it might be a bit more complicated than we&#39;re t=
hinking<br><br>Right, good catch, this does require new logic to handle thi=
s case.<br>As Gloria points out, this should be doable, and is definitely w=
orth<br>adding (those CSV 1 on every other output are really hacky, glad to=
<br>find a way to get rid of them).<br><br>Thanks,<br>Bastien</div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 2=
6 sept. 2022 =C3=A0=C2=A018:48, Gloria Zhao &lt;<a href=3D"mailto:gloriajzh=
ao@gmail.com" target=3D"_blank">gloriajzhao@gmail.com</a>&gt; a =C3=A9crit=
=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">Hi Greg, Antoine, Bastien, =C2=A0<br>=C2=A0 <br>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&#39;m wrong). I&#39;ll try to respond to as much as possib=
le.<br><br>Also I realize that I didn&#39;t contextualize this proposal cle=
arly enough; it is very tailored for LN Penalty and definitely doesn&#39;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 &quot;RBF =
Improvements&quot; post in January, but it doesn&#39;t seem like we&#39;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.<b=
r><br>&gt; 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 &quot;inflated&quot; by tacking on additional inputs=
, this means the total weight of the parent tx lowers the effective feerate=
 of the package. =C2=A0<br>=C2=A0 <br>(For more context to other readers I =
wrote an explanation for this in &quot;SIGHASH_ANYONECANPAY Pinning&quot; s=
ection of RBF ML post).=C2=A0 Yes, this unfortunately doesn&#39;t fix any o=
f the existing pinning attacks for single transaction RBF but also doesn&#3=
9;t make them worse. This boils down to adding an incentive compatibility r=
ule that ensures you can&#39;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).<br><br>So in the scenario =
above with the &quot;inflated&quot; 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&#39;t recommend it for single transaction replacement. S=
o that attack still exists for single transactions, yes. =C2=A0<br><br>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&#39;t use ACP, though obviously I agree we should =
fix it for the future.<br><br>So when I said &quot;this is intended for fee=
-bumping presigned txns in contracting protocols,&quot; I should have said =
&quot;this is intended for fee-bumping presigned txns specifically using CP=
FP and anchor outputs.&quot; Apologies for forgetting to contextualize, I&#=
39;ve been sitting on this for too long.<br>=C2=A0 <br>&gt; The other scena=
rio it doesn&#39;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 &quot;self-pin&quot; and &quo=
t;get good at utxos noob&quot; type problem, but it&#39;s something that ax=
ing rule#3 in favor of a Replace-by-ancestor-feerate system would get us. =
=C2=A0<br>=C2=A0 <br>I understand you to mean &quot;if you don&#39;t have e=
nough UTXOs and you&#39;re forced to batch-bump, you over-pay because you n=
eed to bring them all to the highest target feerate.&quot; Isn&#39;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&#39=
;t be batched... I don&#39;t see how a replace-by-ancestor-feerate policy w=
ould make any difference for this?<br><br>Also in general I&#39;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.<br><br>We&#39;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&#39;t want to overestimate how good the repl=
acement is, and we don&#39;t want to underestimate how good the original tr=
ansactions are. This rule &quot;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&quot; is a conservative estimate.<br><br>&gt; Would kind of =
be nice if package RBF would detect a &quot;sibling output spend&quot; 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.<br><br>Interesti=
ng, so when a transaction hits a mempool tx&#39;s descendant limit, we cons=
ider evicting one of its descendants in favor of this transaction, based on=
 the RBF rules.<br>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. <br>=C2=A0 <br>&gt; If yo=
u&#39;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<br>&gt; So I&#39;m not sure if those two rules are compatible with m=
iners incentives... =C2=A0<br>=C2=A0 <br>The same argument can be made for =
the 26th descendant of a mempool transaction; it&#39;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 &quot;help the Bitcoin ecosystem&quot; 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&#39;s worth it.<br>=C2=A0 <br>&gt;=
 &gt; 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be =C2=
=A0 =C2=A0<br>&gt; &gt; =C2=A0 =C2=A0larger than 1000 virtual bytes. =C2=A0=
 =C2=A0<br>=C2=A0 =C2=A0<br>&gt; 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<br>=C2=A0 <br><div>Yeah exactly, the &q=
uot;Rule 3 pin&quot; is done by adding a child that&#39;s high-fee (so you =
have to pay that much to evict it). Because they *don&#39;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&#39;t increase the replacement cost without al=
so fee-bumping the transaction to make it confirm faster.=C2=A0 </div><br>&=
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&#39;ll always have tricky fingerprints leaking from unilateral=
 LN closures such as HTLC/PTLC timelocks... =C2=A0<br><div><br></div><div>&=
gt; I agree with you, this isn&#39;t worse than today, unilateral closes wi=
ll</div><div>probably always be identifiable on-chain.</div><br>Great to he=
ar that there is no privacy worsening!<br><br>Best, =C2=A0<br>Gloria<br></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Mon, Sep 26, 2022 at 5:02 PM Greg Sanders &lt;<a href=3D"mailto:gsanders87@=
gmail.com" target=3D"_blank">gsanders87@gmail.com</a>&gt; wrote:<br></div><=
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"><div dir=3D"ltr">Bastien,<=
div><br></div><div>&gt; This may be already covered by the current package =
RBF logic, in that</div>scenario we are simply replacing [ParentTx, ChildTx=
1] with<br>[ParentTx, ChildTx2] that pays more fees, right?<div><br></div><=
div>For clarification, package RBF is ParentTx*s*(plural), and ChildTx(sing=
ular), so it might be a bit more complicated than we&#39;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 &quot;rest&quot; of the transact=
ions as a package, then individually. Not the same, not sure how different.=
 I&#39;ll defer to experts.</div><div><br></div><div>Best,</div><div>Greg</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Thanks Gloria for th=
is great post.<br><br>This is very valuable work for L2 contracts, and will=
 greatly improve<br>their security model.<br><br>&gt; &quot;Only 1 anchor o=
utput? What if I need to bump counterparty&#39;s commitment tx in mempool?&=
quot;<br>&gt; You won&#39;t need to fee-bump a counterparty&#39;s commitmen=
t tx using CPFP.<br>&gt; You would just package RBF it by attaching a high-=
feerate child to<br>&gt; your commitment tx.<br><br>Note that we can also v=
ery easily make that single anchor spendable by<br>both participants (or ev=
en anyone), so if you see your counterparty&#39;s<br>commitment in your mem=
pool, you can bump it without publishing your<br>own commitment, which is q=
uite desirable (your own commitment tx has<br>CSV delays on your outputs, w=
hereas your counterparty&#39;s commitment tx<br>doesn&#39;t).<br><br>&gt; &=
quot;Is this a privacy issue, i.e. doesn&#39;t it allow fingerprinting LN<b=
r>transactions based on nVersion?&quot;<br><br>I agree with you, this isn&#=
39;t worse than today, unilateral closes will<br>probably always be identif=
iable on-chain.<br><br>&gt; Would kind of be nice if package RBF would dete=
ct a &quot;sibling output spend&quot;<br>&gt; conflict, and knock it out of=
 the mempool via the other replacement rules?<br>&gt; Getting rid of the re=
quirement to 1 block csv lock every output would be<br>&gt; quite nice from=
 a smart contracting composability point of view.<br><br>+1, that would be =
very neat!<br><br>This may be already covered by the current package RBF lo=
gic, in that<br>scenario we are simply replacing [ParentTx, ChildTx1] with<=
br>[ParentTx, ChildTx2] that pays more fees, right?<br><br>&gt; 1) I do thi=
nk that we should seriously consider allowing OP_TRUE to become<br>&gt; a s=
tandard script type as part of this policy update. If pinning is solved,<br=
>&gt; then there&#39;s no reason to require all those extra bytes for &quot=
;binding&quot; an<br>&gt; anchor to a specific wallet/user. We can save qui=
te a few bytes by having<br>&gt; the input be empty of witness data.<br>&gt=
; 2) If we allow for a single dust-value(0 on up) output which is immediate=
ly<br>&gt; spent by the package, anchors become even easier to to design. N=
o value has<br>&gt; to be &quot;sapped&quot; from contract participants to =
make an anchor output. There&#39;s<br>&gt; more complications for this, suc=
h as making sure the parent transaction is<br>&gt; dropped if the child spe=
nd is dropped, but maybe it&#39;s worth the squeeze.<br><br>I also think bo=
th of these could be quite useful. This would probably always<br>be used in=
 combination with a parent transaction that pays 0 fees, so the<br>0-value =
output would always be spent in the same block.<br><br>But this means we co=
uld end up with 0-value outputs in the utxo set, if for<br>some reason the =
parent tx is CPFP-ed via another output than the 0-value one,<br>which woul=
d be a utxo set bloat issue. But I&#39;d argue that we&#39;re probably<br>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 would<br=
>probably be *better* than what we&#39;re doing today.<br><br>Thanks,<br>Ba=
stien</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">Le=C2=A0lun. 26 sept. 2022 =C3=A0=C2=A003:22, Antoine Riard via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=
=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr">Hi Gloria,<br><br>Thanks for the progress on package RBF, few early q=
uestions.<br><br>&gt; 2. Any descendant of an unconfirmed V3 transaction mu=
st also be V3.<br><br>&gt; 3. An unconfirmed V3 transaction cannot have mor=
e than 1 descendant.<br><br>If you&#39;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.<br><br>So I&#39;m not sure if those two rules are compati=
ble with miners incentives...<br><br>&gt; 4. A V3 transaction that has an u=
nconfirmed V3 ancestor cannot be<br>&gt; =C2=A0 =C2=A0larger than 1000 virt=
ual bytes.<br><br>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.<br><br>I still wonder if this compatible with miner incentive=
s in period of empty mempools, in the sense that if you&#39;ve already a V3=
 transaction of size 100Kvb offering 2 sat/vb, it&#39;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.<br><br>(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...)<br><br>&gt; (Lower bound) the smaller this lim=
it, the fewer UTXOs a child may use<br>&gt; to fund this fee-bump. For exam=
ple, only allowing the V3 child to have<br>&gt; 2 inputs would require L2 p=
rotocols to manage a wallet with high-value<br>&gt; UTXOs and make batched =
fee-bumping impossible. However, as the<br>&gt; fee-bumping child only need=
s to fund fees (as opposed to payments),<br>&gt; just a few UTXOs should su=
ffice.<br><br>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 &quot;cat-and-mouse&quot; 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.<br><br>On the other hand, I wonder if we wouldn&#39;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&#39;t need to do unilateral closure. Let&#39;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.<br><br>&gt; 1. The rule around unconf=
irmed inputs was<br>&gt; originally &quot;A package may include new unconfi=
rmed inputs, but the<br>&gt; ancestor feerate of the child must be at least=
 as high as the ancestor<br>&gt; feerates of every transaction being replac=
ed.&quot;<br><br>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 &quot;at least as high ancestor =
feerate&quot; HTLC-timeout transaction. With `option_anchor_outputs&quot; t=
here is no unconfirmed ancestor to replace, as the commitment transaction, =
whatever the party it is originating from, should already be confirmed.<br>=
<br>&gt; &quot;Is this a privacy issue, i.e. doesn&#39;t it allow fingerpri=
nting LN<br>transactions based on nVersion?&quot;<br><br>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&#39;ll al=
ways have tricky fingerprints leaking from unilateral LN closures such as H=
TLC/PTLC timelocks...<br><br>&gt; &quot;Can a V2 transaction replace a V3 t=
ransaction and vice versa?&quot;<br><br>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&#39;t be pinning vectors. Currentl=
y, commitment transactions signal replaceability.<br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 23 sept=
. 2022 =C3=A0=C2=A011:26, Gloria Zhao via bitcoin-dev &lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi everyone,<br><br>I&#39=
;m writing to propose a very simple set of mempool/transaction relay<br>pol=
icies intended to aid L2/contract protocols. I realized that<br>the previou=
sly proposed Package Mempool Accept package RBF [1]<br><div>had a few remai=
ning problems after digging into the RBF logic more [2].</div><div>This add=
itional set of policies solves them without requiring a huge RBF overhaul.<=
br></div><br>I&#39;ve written an implementation (and docs) for Bitcoin Core=
:<br><a href=3D"https://github.com/bitcoin/bitcoin/pull/25038" target=3D"_b=
lank">https://github.com/bitcoin/bitcoin/pull/25038</a><br><br>(You may not=
ice that this proposal incorporates feedback on the PR - thanks Suhas Daftu=
ar, Gregory Sanders, Bastien Teinturier, Anthony Towns, and others.)<br><br=
>If you are interested in using package RBF/relay to bump presigned<br>tran=
sactions, I think you may be interested in reviewing this proposal.<br>This=
 should solve Rule 3 pinning and perhaps allow us<br>to get rid of CPFP car=
ve-out (yay!). I&#39;m keen to hear if people find<br>the 1-anchor-output, =
1000vB child limit too restrictive. Also, if you find a<br>pinning attack o=
r something that makes it unusable for you, I would<br>really really like t=
o know.<br><br>Note that transactions with nVersion=3D3 (&quot;V3 transacti=
ons&quot;) are<br>currently non-standard in Bitcoin Core. That means **anyt=
hing that was<br>standard before this policy change would still be standard=
<br>afterwards.** If you don&#39;t want your transactions to be subject to<=
br>these rules, just continue whatever you&#39;re doing and don&#39;t use<b=
r>nVersion=3D3. AFAICT this shouldn&#39;t break anything, but let me know i=
f<br>this would be disruptive for you?<br><br>**New Policies:**<br><br>This=
 includes:<br>- a set of additional policy rules applying to V3 transaction=
s<br>- modifications to package RBF rules<br><br>**V3 transactions:**<br><b=
r>Existing standardness rules apply to V3 (e.g. min/max tx weight,<br>stand=
ard output types, cleanstack, etc.). The following additional<br>rules appl=
y to V3:<br><br>1. A V3 transaction can be replaced, even if it does not si=
gnal BIP125<br>=C2=A0 =C2=A0replaceability. (It must also meet the other RB=
F rules around fees,<br>etc. for replacement to happen).<br><br>2. Any desc=
endant of an unconfirmed V3 transaction must also be V3.<br><br>*Rationale*=
: Combined with Rule 1, this gives us the property of<br>&quot;inherited&qu=
ot; replaceability signaling when descendants of unconfirmed<br>transaction=
s are created. Additionally, checking whether a transaction<br>signals repl=
aceability this way does not require mempool traversal,<br>and does not cha=
nge based on what transactions are mined. It also<br>makes subsequent rules=
 about descendant limits much easier to check.<br><br>*Note*: The descendan=
t of a *confirmed* V3 transaction does not need to be V3.<br><br>3. An unco=
nfirmed V3 transaction cannot have more than 1 descendant.<br><br>*Rational=
e*: (Upper bound) the larger the descendant limit, the more<br>transactions=
 may need to be replaced. This is a problematic pinning<br>attack, i.e., a =
malicious counterparty prevents the transaction from<br>being replaced by a=
dding many descendant transactions that aren&#39;t<br>fee-bumping.<br><br>(=
Lower bound) at least 1 descendant is required to allow CPFP of the<br>pres=
igned transaction. The contract protocol can create presigned<br>transactio=
ns paying 0 fees and 1 output for attaching a CPFP at<br>broadcast time (&q=
uot;anchor output&quot;). Without package RBF, multiple anchor<br>outputs w=
ould be required to allow each counterparty to fee-bump any<br>presigned tr=
ansaction. With package RBF, since the presigned<br>transactions can replac=
e each other, 1 anchor output is sufficient.<br><br>4. A V3 transaction tha=
t has an unconfirmed V3 ancestor cannot be<br>=C2=A0 =C2=A0larger than 1000=
 virtual bytes.<br><br>*Rationale*: (Upper bound) the larger the descendant=
 size limit, the<br>more vbytes may need to be replaced. With default limit=
s, if the child<br>is e.g. 100,000vB, that might be an additional 100,000sa=
ts (at<br>1sat/vbyte) or more, depending on the feerate.<br><br>(Lower boun=
d) the smaller this limit, the fewer UTXOs a child may use<br>to fund this =
fee-bump. For example, only allowing the V3 child to have<br>2 inputs would=
 require L2 protocols to manage a wallet with high-value<br>UTXOs and make =
batched fee-bumping impossible. However, as the<br>fee-bumping child only n=
eeds to fund fees (as opposed to payments),<br>just a few UTXOs should suff=
ice.<br><br>With a limit of 1000 virtual bytes, depending on the output typ=
es, the<br>child can have 6-15 UTXOs, which should be enough to fund a fee-=
bump<br>without requiring a carefully-managed UTXO pool. With 1000 virtual<=
br>bytes as the descendant limit, the cost to replace a V3 transaction<br>h=
as much lower variance.<br><br>*Rationale*: This makes the rule very easily=
 &quot;tacked on&quot; to existing<br>logic for policy and wallets. A trans=
action may be up to 100KvB on its<br>own (`MAX_STANDARD_TX_WEIGHT`) and 101=
KvB with descendants<br>(`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existi=
ng V3 transaction<br>in the mempool is 100KvB, its descendant can only be 1=
000vB, even if<br>the policy is 10KvB.<br><br>**Package RBF modifications:*=
*<br><br>1. The rule around unconfirmed inputs was<br>originally &quot;A pa=
ckage may include new unconfirmed inputs, but the<br>ancestor feerate of th=
e child must be at least as high as the ancestor<br>feerates of every trans=
action being replaced.&quot;<br><br>The package may still include new uncon=
firmed inputs. However,<br>the new rule is modified to be &quot;The minimum=
 between package feerate<br>and ancestor feerate of the child is not lower =
than the individual<br>feerates of all directly conflicting transactions an=
d the ancestor<br>feerates of all original transactions.&quot;<br><br>*Rati=
onale*: We are attempting to ensure that the replacement<br>transactions ar=
e not less incentive-compatible to mine. However, a<br>package/transaction&=
#39;s ancestor feerate is not perfectly representative<br>of its incentive =
compatibility; it may overestimate (some subset of<br>the ancestors could b=
e included by itself if it has other high-feerate<br>descendants or are the=
mselves higher feerate than this<br>package/transaction). Instead, we use t=
he minimum between the package<br>feerate and ancestor feerate of the child=
 as a more conservative value<br>than what was proposed originally.<br><br>=
2. A new rule is added, requiring that all package transactions with<br>mem=
pool conflicts to be V3. This also means the &quot;sponsoring&quot;<br>chil=
d transaction must be V3.<br><br>*Note*: Combined with the V3 rules, this m=
eans the package must be<br>a child-with-parents package. Since package val=
idation is only<br>attempted if the transactions do not pay sufficient fees=
 to be<br>accepted on their own, this effectively means that only V3<br>tra=
nsactions can pay to replace their ancestors&#39; conflicts, and only<br>V3=
 transactions&#39; replacements may be paid for by a descendant.<br><br>*Ra=
tionale*: The fee-related rules are economically rational for<br>ancestor p=
ackages, but not necessarily other types of packages.<br>A child-with-paren=
ts package is a type of ancestor package. It<br>may be fine to allow any an=
cestor package, but it&#39;s more difficult<br>to account for all of the po=
ssibilities. For example, it gets much<br>harder to see that we&#39;re appl=
ying the descendant limits correctly if<br>the package has a gnarly, many-g=
eneration, non-tree shape. I&#39;m also<br>not sure if this policy is 100% =
incentive-compatible if the sponsor<br>is not a direct descendant of the sp=
onsee.<br><br>Please see doc/policy/version3_transactions.md and<br>doc/pol=
icy/packages.md in the PR for the full set of rules.<br><br>**Intended usag=
e for LN:**<br><br>Commitment transactions should be V3 and have 1 anchor o=
utput. They<br>can be signed with 0 fees (or 1sat/vbyte) once package relay=
 is deployed<br>on a significant portion of the network. If the commitment =
tx must<br>be broadcast, determine the desired feerate at broadcast time an=
d<br>spend the anchor output in a high feerate transaction. I&#39;m going t=
o<br>call the broadcasted commitment tx &quot;the parent&quot; and the atta=
ched<br>fee-bumping tx &quot;the child.&quot;<br><br>- This child must be V=
3.<br>- This child must be at most 1000vB. Note this restricts the<br>=C2=
=A0 number of inputs you can use to fund the fee bump. Depending<br>on the =
output types, this is around 6-15.<br>- One child may fund fees for multipl=
e commitment tx (&quot;batched<br>=C2=A0 fee-bumping&quot;).<br>- To do a s=
econd fee-bump to add more fees, replace the<br>=C2=A0 *child* with a highe=
r-feerate tx. Do not try to attach a grandchild.<br><br>Otherwise, never tr=
y to spend from an unconfirmed V3 transaction. The<br>descendant limits for=
 V3 transactions are very restrictive.<br><br>**Expected Questions:**<br><b=
r>&quot;Does this fix Rule 3 Pinning?&quot;<br>Yes. The V3 descendant limit=
 restricts both you and your counterparty.<br>Assuming nodes adopted this p=
olicy, you may reasonably assume that you<br>only need to replace the commi=
tment transaction + up to 1000vB.<br><br>&quot;Only 1 anchor output? What i=
f I need to bump counterparty&#39;s commitment tx in mempool?&quot;<br><div=
>You won&#39;t need to fee-bump a counterparty&#39;s commitment tx using CP=
FP.</div><div>You would just package RBF it by attaching a high-feerate chi=
ld to</div>your commitment tx.<br><br>&quot;Is this a privacy issue, i.e. d=
oesn&#39;t it allow fingerprinting LN<br>transactions based on nVersion?&qu=
ot;<br>Indeed it may be unrealistic to assume V3 transactions will be in<br=
>widespread use outside of L2. IIUC, unilateral closes are already<br>obvio=
us LN transactions because of the HTLC inputs. For e.g.<br>cooperative clos=
es and opens, I think it makes sense to continue using<br>V2. So, unless I&=
#39;m missing something, this shouldn&#39;t make it worse.<br><br>&quot;So =
a V3 transaction that doesn&#39;t signal BIP125 replaceability is<br>replac=
eable? Is that a backward compatibility issue?&quot;<br>Yes it&#39;s replac=
eable. It&#39;s not an issue AFAICT because,<br>under previous policy, the =
V3 transaction wouldn&#39;t have been<br>in the mempool in the first place.=
<br><br>&quot;Can a V2 transaction replace a V3 transaction and vice versa?=
&quot;<br>Yes, otherwise someone can use V3 transactions to censor V2<br>tr=
ansactions spending shared inputs. Note if the<br>original V3 transaction h=
as an unconfirmed V3 parent, this would<br>violate the &quot;inherited V3&q=
uot; rule and would be rejected.<br><br>Thanks for reading! Feedback and re=
view would be much appreciated.<br><br>[1]: <a href=3D"https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2021-September/019464.html" target=3D"_=
blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Septemb=
er/019464.html</a><br><div>[2]: <a href=3D"https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2022-January/019817.html" target=3D"_blank">https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html</=
a></div><div><br></div>Best,<br>Gloria</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>

--000000000000075e2705e9d1e0c9--