path: root/f4/20bb3d4f4fb40fbca479dc66ae8d324c2989c8

Return-Path: <rsomsen@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BD81DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 Oct 2022 10:00:08 +0000 (UTC)
Received: by mail-oo1-xc29.google.com with SMTP id
 z9-20020a4a4909000000b0047651b95fbdso3810408ooa.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <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>
 <CAB3F3DvCw9Ms+HUMaFnqV0P-Oo+rfERY+j5S5CC_X2NKRd5u8g@mail.gmail.com>
 <CAPv7TjYM34qk5bGheMZhopotuCwxYyHmWAXcawA5UHQpQWiGCg@mail.gmail.com>
 <CACdvm3MTSVDOSLmpDTzs6Gj1Oz-9rDgPKY=ipMdV9iJzQhE-ew@mail.gmail.com>
 <CAB3F3Dtx58n1U0sK4ev6UwSqLJ8nn=wgJJE8V6YrWt4yeZ_4Yw@mail.gmail.com>
In-Reply-To: <CAB3F3Dtx58n1U0sK4ev6UwSqLJ8nn=wgJJE8V6YrWt4yeZ_4Yw@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Sat, 1 Oct 2022 11:59:55 +0200
Message-ID: <CAPv7TjbeCYeO2mH3rL1cxT2F4-kR_pyzeroD1hpnG_WPH6EQ9g@mail.gmail.com>
To: Bastien TEINTURIER <bastien@acinq.fr>
Content-Type: multipart/alternative; boundary="000000000000d5ef2205e9f62c34"
X-Mailman-Approved-At: Sat, 01 Oct 2022 10:19:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Greg Sanders <gsanders87@gmail.com>
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: 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 <gsanders87@gmail.com> 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 <bastien@acinq.fr> 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 <rsomsen@gmail.com> 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 <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 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 <gloriajzhao@gmail.co=
m> 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 <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 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

<div dir=3D"ltr">Hi Bastien,<div><br></div><div>&gt;Greg already has a draf=
t design that addresses your concerns</div><div><br></div><div>Thanks, that=
 is very nice. In that case I currently have no outstanding objections.</di=
v><div><br></div><div>&gt;I&#39;m curious why you would need more than one =
such output</div><div><br></div><div>My reasoning was actually to allow onl=
y one OP_TRUE output per transaction, so I think we agree. Apologies if tha=
t wasn&#39;t clear.</div><div><br></div><div>To summarize:</div><div><br></=
div><div>1. OP_TRUE output must be spent</div><div>2. Only one child allowe=
d per transaction</div><div><br></div><div>This ensures there is no scenari=
o where a child is propagated that does not spend the OP_TRUE output.</div>=
<div><br></div><div>Cheers,</div><div>Ruben</div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 30, 2022 at 2:=
17 PM Greg Sanders &lt;<a href=3D"mailto:gsanders87@gmail.com">gsanders87@g=
mail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"auto">It&#39;s likely better if the ephemeral output ca=
n be any value, including dust. This lets contract designers put &quot;trim=
med output&quot; value indirectly towards CPFP fees without making the pare=
nt tx have fees itself.=C2=A0</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Sep 30, 2022, 8:08 AM Bastien TEINTUR=
IER &lt;<a href=3D"mailto:bastien@acinq.fr" target=3D"_blank">bastien@acinq=
.fr</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr">Hey Ruben,<br><br>I discussed this further over IRC, an=
d I now agree that this particular<br>change would be very desirable and ca=
n likely fit in the initial release<div>(even though I&#39;m not the one wr=
iting that code, but I&#39;d be happy to<br>review it and test it).</div><d=
iv><br>Greg already has a draft design that addresses your concerns: if the=
re is<br>an &quot;ephemeral output&quot; (0-value, OP_TRUE) in an unconfirm=
ed v3 transaction,<br>it MUST be spent by any child v3 transaction. This wa=
y, you ensure that<br>any child transaction spending the unconfirmed parent=
 spends the ephemeral<br>output(s). @Greg, correct me if I misunderstood so=
mething here. Note that<br>we will need to precisely define the criteria fo=
r those &quot;ephemeral outputs&quot;<br>(it can probably simply be &quot;o=
utputs that are 0 sats&quot;).<br><br>Coupled with transactions that pay no=
 fees (and thus require a child to<br>CPFP in order to be included in a blo=
ck), this ensures those outputs can<br>never leak into the utxo set. How do=
es that sound?<br><br>I&#39;m curious why you would need more than one such=
 output, can you detail?<br>I believe we only ever need one, spendable by a=
nyone.<br><br>Cheers,<br>Bastien</div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 30 sept. 2022 =C3=A0=C2=
=A002:14, Ruben Somsen &lt;<a href=3D"mailto:rsomsen@gmail.com" rel=3D"nore=
ferrer" target=3D"_blank">rsomsen@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv>Hi Bastien,</div><div><br></div>&gt;The other change mentioned (making O=
P_TRUE standard and allowing outputs<br>that are below dust) can be added l=
ater, as those won&#39;t be standard until<br>we start allowing them, so th=
ere shouldn&#39;t be any backwards-compatibility<br>issue with postponing t=
his change. But maybe it&#39;s still worth having 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<div><br></div><div>I&#39;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.</div><div><br></div><div>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:<br></div><div>- Another CPFP tx can feebump the pac=
kage on a different (non-OP_TRUE) output with an even higher fee rate</div>=
<div>- Subsequently, the tx that is spending the OP_TRUE might fall out of =
the mempool if the mempool fee rate rises</div><div>- This could cause the =
0 sat output to enter the UTXO set (specifically, rational miners wouldn&#3=
9;t refuse to mine such a tx)</div><div><br></div><div>It doesn&#39;t seem =
like this would happen much in practice (nor is there an incentive to do it=
 on purpose), but the chance isn&#39;t 0.</div><div><br></div><div>Cheers,<=
/div><div>Ruben</div><div><br></div><div><br></div><div></div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 2=
9, 2022 at 4:50 PM Greg Sanders via bitcoin-dev &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" rel=3D"noreferrer" target=3D"_blank">bitc=
oin-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 solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">&gt; Right, good catch, t=
his does require new logic to handle this case.<br>As Gloria points out, th=
is should be doable, and is definitely worth<br>adding (those CSV 1 on ever=
y other output are really hacky, glad to<br>find a way to get rid of them).=
<div><br></div><div>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!</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 &l=
t;<a href=3D"mailto:bastien@acinq.fr" rel=3D"noreferrer" target=3D"_blank">=
bastien@acinq.fr</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr">Hi Gloria, Greg,<br><br>&gt; I interpret m=
ost of the discussion around limitations as ideas for<br>&gt; future improv=
ements rather than criticisms of the proposal<br><br>As far as I&#39;m conc=
erned, definitely!<br><br>My current understanding is that the main change/=
improvement that would<br>make sense here is restricting the whole v3 packa=
ge&#39;s size (instead of<br>just the child) via committing to a specific v=
alue in the taproot annex<br>(also note that it&#39;s probably not just the=
 v3 package&#39;s size, it should<br>be the whole unconfirmed package inclu=
ding potential v2 unconfirmed<br>ancestors).<br><br>While I think this woul=
d be very valuable and would like to see this<br>happen, I believe that can=
 be done in a second, separate step since this<br>would make relay policy s=
tricter (some v3 transactions that previously<br>propagated wouldn&#39;t pr=
opagate under this new rule). As long as you are<br>able to find a path to =
miners through upgraded peers that use this annex<br>approach, you should b=
e able to resolve ACP pinning issues?<br><br>I&#39;m curious to know how ot=
her people feel about that: is it ok to do<br>later or should we try to imp=
lement this for the first release of v3<br>transactions?<br><br>The other c=
hange mentioned (making OP_TRUE standard and allowing outputs<br>that are b=
elow dust) can be added later, as those won&#39;t be standard until<br>we s=
tart allowing them, so there shouldn&#39;t be any backwards-compatibility<b=
r>issue with postponing this change. But maybe it&#39;s still worth having =
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 ge=
t all of those directly<br>in the first release of v3 transactions, but I d=
on&#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 ChildTx(sin=
gular),<br>&gt; so it might be a bit more complicated than we&#39;re thinki=
ng<br><br>Right, good catch, this does require new logic to handle this cas=
e.<br>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<br>f=
ind a way to get rid of them).<br><br>Thanks,<br>Bastien</div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 26 sep=
t. 2022 =C3=A0=C2=A018:48, Gloria Zhao &lt;<a href=3D"mailto:gloriajzhao@gm=
ail.com" rel=3D"noreferrer" target=3D"_blank">gloriajzhao@gmail.com</a>&gt;=
 a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: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>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&#39;m wrong). I&#39;ll try to respond to as m=
uch as possible.<br><br>Also I realize that I didn&#39;t contextualize this=
 proposal clearly enough; it is very tailored for LN Penalty and definitely=
 doesn&#39;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 &quot;RBF Improvements&quot; post in January, but it doesn&#39;t seem li=
ke we&#39;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.<br><br>&gt; 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 &quot;inflated&quot; 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<br>=C2=A0 <br>(For more context to oth=
er readers I wrote an explanation for this in &quot;SIGHASH_ANYONECANPAY Pi=
nning&quot; section of RBF ML post).=C2=A0 Yes, this unfortunately doesn&#3=
9;t fix any of the existing pinning attacks for single transaction RBF but =
also doesn&#39;t make them worse. This boils down to adding an incentive co=
mpatibility rule that ensures you can&#39;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).<br><br>So in =
the scenario above with the &quot;inflated&quot; 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&#39;t recommend it for single transaction r=
eplacement. So 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 cha=
llenges but hopefully has no current use cases as you say. AFAIK LN Penalty=
 is not affected by this since it doesn&#39;t use ACP, though obviously I a=
gree we should fix it for the future.<br><br>So when I said &quot;this is i=
ntended for fee-bumping presigned txns in contracting protocols,&quot; I sh=
ould have said &quot;this is intended for fee-bumping presigned txns specif=
ically using CPFP and anchor outputs.&quot; Apologies for forgetting to con=
textualize, I&#39;ve been sitting on this for too long.<br>=C2=A0 <br>&gt; =
The other scenario it doesn&#39;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 &quot;self-pin=
&quot; and &quot;get good at utxos noob&quot; type problem, but it&#39;s so=
mething that axing 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 do=
n&#39;t have enough UTXOs and you&#39;re forced to batch-bump, you over-pay=
 because you need to bring them all to the highest target feerate.&quot; Is=
n&#39;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&#39;t be batched... I don&#39;t see how a replace-by-ancestor-fe=
erate policy would make any difference for this?<br><br>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.<br><br>We&#39;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&#39;t want to overestimate how=
 good the replacement is, and we don&#39;t want to underestimate how good t=
he original transactions are. This rule &quot;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&quot; is a conservative estimate.<br><br>&gt; =
Would kind of be nice if package RBF would detect a &quot;sibling output sp=
end&quot; 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.<br=
><br>Interesting, so when a transaction hits a mempool tx&#39;s descendant =
limit, we consider evicting one of its descendants in favor of this transac=
tion, 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 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. <br>=C2=A0 =
<br>&gt; 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 such a transaction. =
=C2=A0 =C2=A0 =C2=A0<br>&gt; So I&#39;m not sure if those two rules are com=
patible with miners incentives... =C2=A0<br>=C2=A0 <br>The same argument ca=
n be made for the 26th descendant of a mempool transaction; it&#39;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 &quot;help the Bitcoin ecosystem&quot; 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&#39;s worth it.<br>=
=C2=A0 <br>&gt; &gt; 4. A V3 transaction that has an unconfirmed V3 ancesto=
r cannot be =C2=A0 =C2=A0<br>&gt; &gt; =C2=A0 =C2=A0larger than 1000 virtua=
l bytes. =C2=A0 =C2=A0<br>=C2=A0 =C2=A0<br>&gt; 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<br>=C2=A0 <br><div>Yeah =
exactly, the &quot;Rule 3 pin&quot; is done by adding a child that&#39;s hi=
gh-fee (so you have to pay that much to evict it). Because they *don&#39;t*=
 want this tx to confirm, normally, this child would be really large. If th=
ey only have 1000vB for the child, they can&#39;t increase the replacement =
cost without also 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 transaction=
s. 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, unila=
teral closes will</div><div>probably always be identifiable on-chain.</div>=
<br>Great to hear that there is no privacy worsening!<br><br>Best, =C2=A0<b=
r>Gloria<br></div><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"mai=
lto:gsanders87@gmail.com" rel=3D"noreferrer" target=3D"_blank">gsanders87@g=
mail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr">Bastien,<div><br></div><div>&gt; This may be alrea=
dy covered by the current package RBF logic, in that</div>scenario we are s=
imply replacing [ParentTx, ChildTx1] with<br>[ParentTx, ChildTx2] that pays=
 more fees, right?<div><br></div><div>For clarification, package RBF is Par=
entTx*s*(plural), and ChildTx(singular), so it might be a bit more complica=
ted than we&#39;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 &quot;rest&quot; of the transactions 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_attr">On Mon, Sep 26, 2022 at 11:48 AM Bast=
ien TEINTURIER via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" rel=3D"noreferrer" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr">Thanks Gloria for this great post.<br><br>=
This is very valuable work for L2 contracts, and will greatly improve<br>th=
eir security model.<br><br>&gt; &quot;Only 1 anchor output? 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 commitment tx using CPFP.<br>&g=
t; You would just package RBF it by attaching a high-feerate child to<br>&g=
t; your commitment tx.<br><br>Note that we can also very easily make that s=
ingle anchor spendable by<br>both participants (or even anyone), so if you =
see your counterparty&#39;s<br>commitment in your mempool, you can bump it =
without publishing your<br>own commitment, which is quite desirable (your o=
wn commitment tx has<br>CSV delays on your outputs, whereas your counterpar=
ty&#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<br>transactions based o=
n nVersion?&quot;<br><br>I agree with you, this isn&#39;t worse than today,=
 unilateral closes will<br>probably always be identifiable on-chain.<br><br=
>&gt; Would kind of be nice if package RBF would detect a &quot;sibling out=
put spend&quot;<br>&gt; conflict, and knock it out of the mempool via the o=
ther replacement rules?<br>&gt; Getting rid of the requirement to 1 block c=
sv lock every output would be<br>&gt; quite nice from a smart contracting c=
omposability point of view.<br><br>+1, that would be very neat!<br><br>This=
 may be already covered by the current package RBF logic, in that<br>scenar=
io we are simply replacing [ParentTx, ChildTx1] with<br>[ParentTx, ChildTx2=
] that pays more fees, right?<br><br>&gt; 1) I do think that we should seri=
ously consider allowing OP_TRUE to become<br>&gt; a standard 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 quite a few bytes by havi=
ng<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 immediately<br>&gt; spent by th=
e package, anchors become even easier to to design. No 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, such as making sure the p=
arent transaction is<br>&gt; dropped if the child spend is dropped, but may=
be it&#39;s worth the squeeze.<br><br>I also think both of these could be q=
uite useful. This would probably always<br>be used in combination with a pa=
rent 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 could end up with 0-valu=
e outputs in the utxo set, if for<br>some reason the parent tx is CPFP-ed v=
ia another output than the 0-value one,<br>which would be a utxo set bloat =
issue. But I&#39;d argue that we&#39;re probably<br>already creating utxo s=
et 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>Bastien</div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 26 s=
ept. 2022 =C3=A0=C2=A003:22, Antoine Riard via bitcoin-dev &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer" 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">H=
i Gloria,<br><br>Thanks for the progress on package RBF, few early question=
s.<br><br>&gt; 2. Any descendant of an unconfirmed V3 transaction must also=
 be V3.<br><br>&gt; 3. An unconfirmed V3 transaction cannot have more 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 such a tr=
ansaction.<br><br>So I&#39;m not sure if those two rules are compatible wit=
h miners incentives...<br><br>&gt; 4. A V3 transaction that has an unconfir=
med V3 ancestor cannot be<br>&gt; =C2=A0 =C2=A0larger than 1000 virtual byt=
es.<br><br>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.<br><br>I still wonder if this compatible with miner incentives in pe=
riod of empty mempools, in the sense that if you&#39;ve already a V3 transa=
ction of size 100Kvb offering 2 sat/vb, it&#39;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.<br><br>(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...)<br><br>&gt; (Lower bound) the smaller this limit, the=
 fewer UTXOs a child may use<br>&gt; to fund this fee-bump. For example, on=
ly allowing the V3 child to have<br>&gt; 2 inputs would require L2 protocol=
s to manage a wallet with high-value<br>&gt; UTXOs and make batched fee-bum=
ping impossible. However, as the<br>&gt; fee-bumping child only needs to fu=
nd fees (as opposed to payments),<br>&gt; just a few UTXOs should suffice.<=
br><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 &quot;cat-and-mouse&quot; game to replace one of the batch element at=
 each block to delay confirmation of the remaining elements in the batch, 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-bumping res=
erve pool, as the cost of acquiring UTXO is non-null and in the optimistic =
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 feed the=
 remaining in-flight channels.<br><br>&gt; 1. The rule around unconfirmed i=
nputs was<br>&gt; originally &quot;A package may include new unconfirmed in=
puts, but the<br>&gt; ancestor feerate of the child must be at least as hig=
h as the ancestor<br>&gt; feerates of every transaction being replaced.&quo=
t;<br><br>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 &quot;at least as high ancestor feerate=
&quot; HTLC-timeout transaction. With `option_anchor_outputs&quot; there is=
 no unconfirmed ancestor to replace, as the commitment transaction, whateve=
r 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 fingerprinting L=
N<br>transactions based on nVersion?&quot;<br><br>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&#39;ll always ha=
ve tricky fingerprints leaking from unilateral LN closures such as HTLC/PTL=
C timelocks...<br><br>&gt; &quot;Can a V2 transaction replace a V3 transact=
ion and vice versa?&quot;<br><br>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&#39;t be pinning vectors. Currently, comm=
itment 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:bitcoi=
n-dev@lists.linuxfoundation.org" rel=3D"noreferrer" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><bloc=
kquote 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 everyone,<=
br><br>I&#39;m writing to propose a very simple set of mempool/transaction =
relay<br>policies intended to aid L2/contract protocols. I realized that<br=
>the previously proposed Package Mempool Accept package RBF [1]<br><div>had=
 a few remaining problems after digging into the RBF logic more [2].</div><=
div>This additional set of policies solves them without requiring a huge RB=
F 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" =
rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pul=
l/25038</a><br><br>(You may notice that this proposal incorporates feedback=
 on the PR - thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Ant=
hony Towns, and others.)<br><br>If you are interested in using package RBF/=
relay to bump presigned<br>transactions, I think you may be interested in r=
eviewing this proposal.<br>This should solve Rule 3 pinning and perhaps all=
ow us<br>to get rid of CPFP carve-out (yay!). I&#39;m keen to hear if peopl=
e find<br>the 1-anchor-output, 1000vB child limit too restrictive. Also, if=
 you find a<br>pinning attack or something that makes it unusable for you, =
I would<br>really really like to know.<br><br>Note that transactions with n=
Version=3D3 (&quot;V3 transactions&quot;) are<br>currently non-standard in =
Bitcoin Core. That means **anything 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<br>nVersion=3D3. AFAICT this shouldn&#39;t br=
eak anything, but let me know if<br>this would be disruptive for you?<br><b=
r>**New Policies:**<br><br>This includes:<br>- a set of additional policy r=
ules applying to V3 transactions<br>- modifications to package RBF rules<br=
><br>**V3 transactions:**<br><br>Existing standardness rules apply to V3 (e=
.g. min/max tx weight,<br>standard output types, cleanstack, etc.). The fol=
lowing additional<br>rules apply to V3:<br><br>1. A V3 transaction can be r=
eplaced, even if it does not signal BIP125<br>=C2=A0 =C2=A0replaceability. =
(It must also meet the other RBF rules around fees,<br>etc. for replacement=
 to happen).<br><br>2. Any descendant of an unconfirmed V3 transaction must=
 also be V3.<br><br>*Rationale*: Combined with Rule 1, this gives us the pr=
operty of<br>&quot;inherited&quot; replaceability signaling when descendant=
s of unconfirmed<br>transactions are created. Additionally, checking whethe=
r a transaction<br>signals replaceability this way does not require mempool=
 traversal,<br>and does not change based on what transactions are mined. It=
 also<br>makes subsequent rules about descendant limits much easier to chec=
k.<br><br>*Note*: The descendant of a *confirmed* V3 transaction does not n=
eed to be V3.<br><br>3. An unconfirmed V3 transaction cannot have more than=
 1 descendant.<br><br>*Rationale*: (Upper bound) the larger the descendant =
limit, the more<br>transactions may need to be replaced. This is a problema=
tic pinning<br>attack, i.e., a malicious counterparty prevents the transact=
ion from<br>being replaced by adding many descendant transactions that aren=
&#39;t<br>fee-bumping.<br><br>(Lower bound) at least 1 descendant is requir=
ed to allow CPFP of the<br>presigned transaction. The contract protocol can=
 create presigned<br>transactions paying 0 fees and 1 output for attaching =
a CPFP at<br>broadcast time (&quot;anchor output&quot;). Without package RB=
F, multiple anchor<br>outputs would be required to allow each counterparty =
to fee-bump any<br>presigned transaction. With package RBF, since the presi=
gned<br>transactions can replace each other, 1 anchor output is sufficient.=
<br><br>4. A V3 transaction that has an unconfirmed V3 ancestor cannot be<b=
r>=C2=A0 =C2=A0larger than 1000 virtual bytes.<br><br>*Rationale*: (Upper b=
ound) the larger the descendant size limit, the<br>more vbytes may need to =
be replaced. With default limits, if the child<br>is e.g. 100,000vB, that m=
ight be an additional 100,000sats (at<br>1sat/vbyte) or more, depending on =
the feerate.<br><br>(Lower bound) 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 wit=
h high-value<br>UTXOs and make batched fee-bumping impossible. However, as =
the<br>fee-bumping child only needs to fund fees (as opposed to payments),<=
br>just a few UTXOs should suffice.<br><br>With a limit of 1000 virtual byt=
es, depending on the output types, the<br>child can have 6-15 UTXOs, which =
should be enough to fund a fee-bump<br>without requiring a carefully-manage=
d UTXO pool. With 1000 virtual<br>bytes as the descendant limit, the cost t=
o replace a V3 transaction<br>has 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 transaction may be up to 100KvB on its<br>own (`M=
AX_STANDARD_TX_WEIGHT`) and 101KvB with descendants<br>(`DEFAULT_DESCENDANT=
_SIZE_LIMIT_KVB`). If an existing V3 transaction<br>in the mempool is 100Kv=
B, its descendant can only be 1000vB, even if<br>the policy is 10KvB.<br><b=
r>**Package RBF modifications:**<br><br>1. The rule around unconfirmed inpu=
ts was<br>originally &quot;A package may include new unconfirmed inputs, bu=
t the<br>ancestor feerate of the child must be at least as high as the ance=
stor<br>feerates of every transaction being replaced.&quot;<br><br>The pack=
age may still include new unconfirmed inputs. However,<br>the new rule is m=
odified to be &quot;The minimum between package feerate<br>and ancestor fee=
rate of the child is not lower than the individual<br>feerates of all direc=
tly conflicting transactions and the ancestor<br>feerates of all original t=
ransactions.&quot;<br><br>*Rationale*: We are attempting to ensure that the=
 replacement<br>transactions are not less incentive-compatible to mine. How=
ever, a<br>package/transaction&#39;s ancestor feerate is not perfectly repr=
esentative<br>of its incentive compatibility; it may overestimate (some sub=
set of<br>the ancestors could be included by itself if it has other high-fe=
erate<br>descendants or are themselves higher feerate than this<br>package/=
transaction). Instead, we use the minimum between the package<br>feerate an=
d ancestor feerate of the child as a more conservative value<br>than what w=
as proposed originally.<br><br>2. A new rule is added, requiring that all p=
ackage transactions with<br>mempool conflicts to be V3. This also means the=
 &quot;sponsoring&quot;<br>child transaction must be V3.<br><br>*Note*: Com=
bined with the V3 rules, this means the package must be<br>a child-with-par=
ents package. Since package validation is only<br>attempted if the transact=
ions do not pay sufficient fees to be<br>accepted on their own, this effect=
ively means that only V3<br>transactions can pay to replace their ancestors=
&#39; conflicts, and only<br>V3 transactions&#39; replacements may be paid =
for by a descendant.<br><br>*Rationale*: The fee-related rules are economic=
ally rational for<br>ancestor packages, but not necessarily other types of =
packages.<br>A child-with-parents package is a type of ancestor package. It=
<br>may be fine to allow any ancestor package, but it&#39;s more difficult<=
br>to account for all of the possibilities. For example, it gets much<br>ha=
rder to see that we&#39;re applying the descendant limits correctly if<br>t=
he package has a gnarly, many-generation, non-tree shape. I&#39;m also<br>n=
ot sure if this policy is 100% incentive-compatible if the sponsor<br>is no=
t a direct descendant of the sponsee.<br><br>Please see doc/policy/version3=
_transactions.md and<br>doc/policy/packages.md in the PR for the full set o=
f rules.<br><br>**Intended usage for LN:**<br><br>Commitment transactions s=
hould be V3 and have 1 anchor output. 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 desir=
ed feerate at broadcast time and<br>spend the anchor output in a high feera=
te transaction. I&#39;m going to<br>call the broadcasted commitment tx &quo=
t;the parent&quot; and the attached<br>fee-bumping tx &quot;the child.&quot=
;<br><br>- This child must be V3.<br>- This child must be at most 1000vB. N=
ote this restricts the<br>=C2=A0 number of inputs you can use to fund the f=
ee bump. Depending<br>on the output types, this is around 6-15.<br>- One ch=
ild may fund fees for multiple commitment tx (&quot;batched<br>=C2=A0 fee-b=
umping&quot;).<br>- To do a second fee-bump to add more fees, replace the<b=
r>=C2=A0 *child* with a higher-feerate tx. Do not try to attach a grandchil=
d.<br><br>Otherwise, never try to spend from an unconfirmed V3 transaction.=
 The<br>descendant limits for V3 transactions are very restrictive.<br><br>=
**Expected Questions:**<br><br>&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 policy, you may reasonably assume that you<br>o=
nly need to replace the commitment transaction + up to 1000vB.<br><br>&quot=
;Only 1 anchor output? What if 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 CPFP.</div><div>You would just package RBF it by=
 attaching a high-feerate child to</div>your commitment tx.<br><br>&quot;Is=
 this a privacy issue, i.e. doesn&#39;t it allow fingerprinting LN<br>trans=
actions based on nVersion?&quot;<br>Indeed it may be unrealistic to assume =
V3 transactions will be in<br>widespread use outside of L2. IIUC, unilatera=
l closes are already<br>obvious LN transactions because of the HTLC inputs.=
 For e.g.<br>cooperative closes and opens, I think it makes sense to contin=
ue using<br>V2. So, unless I&#39;m missing something, this shouldn&#39;t ma=
ke it worse.<br><br>&quot;So a V3 transaction that doesn&#39;t signal BIP12=
5 replaceability is<br>replaceable? Is that a backward compatibility issue?=
&quot;<br>Yes it&#39;s replaceable. It&#39;s not an issue AFAICT because,<b=
r>under previous policy, the V3 transaction wouldn&#39;t have been<br>in th=
e mempool in the first place.<br><br>&quot;Can a V2 transaction replace a V=
3 transaction and vice versa?&quot;<br>Yes, otherwise someone can use V3 tr=
ansactions to censor V2<br>transactions spending shared inputs. Note if the=
<br>original V3 transaction has an unconfirmed V3 parent, this would<br>vio=
late the &quot;inherited V3&quot; rule and would be rejected.<br><br>Thanks=
 for reading! Feedback and review would be much appreciated.<br><br>[1]: <a=
 href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Septe=
mber/019464.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2021-September/019464.html</a><br><div>=
[2]: <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
2-January/019817.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.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" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>

--000000000000d5ef2205e9f62c34--