path: root/75/08878ce524bdb810ba143b5bdfdb9aedcfc5ea

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 95CB9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 16:02:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 683E660F61
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 16:02:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 683E660F61
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=GzN9Og/1
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 1DROzcwJGGlo
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 16:02:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D6DA860F3E
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com
 [IPv6:2607:f8b0:4864:20::52a])
 by smtp3.osuosl.org (Postfix) with ESMTPS id D6DA860F3E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 16:02:05 +0000 (UTC)
Received: by mail-pg1-x52a.google.com with SMTP id v4so6935722pgi.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 09:02:05 -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=UX1qiDco+7ZOudEtC5gpk9jOav6eQpk3lBPFOhHrfRs=;
 b=GzN9Og/1gIlAPcxJPw4h7B8l3/JnLS9UVzzINYvH6UTVaPqSNdg2CYSjN8bvpnpAL0
 kIoB72TIuGMA4aNuLjbbQMjTai1bh3s5vB0H0YPAZlU9A2p4TleNDBHf9n5pHwNAA7te
 cUXon3VcXzGDT7sZfazPmAcBI/8t5x9wmD4aTiiijYQ9Gi7JVkRNPum5VbfpIOmwFots
 UnQmsTt/L97TXNGStkaT6khgUpy3OdkJpQDo4r77Jd8NfS9IzEldA5RSN7FNJ+C5kjWK
 refGegXrvX9KwSAfsp93MKBY2Cfjh9B9K7QBMCXjTmNUr0atUXF0OQ+l2hajsGndF+TH
 jjyg==
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=UX1qiDco+7ZOudEtC5gpk9jOav6eQpk3lBPFOhHrfRs=;
 b=X69Opm/NNAvR9ku1gK+h2bgXFeeBQHsiExfR6YMqHCVOU/a3GJi/aT6Mc5U7pwi9yv
 86cxNxyMxOiru+OwC/AOAZOeV/brgVSIdoll1FUe2viB2o8kvNZStG3MB7YQbOkmxRUr
 6Y1kgxzFCVWc69mwHCrEsxe0twlEbPDPexCVMmK0/WRZ9LPE5ABUZ+0tlKHVEPxZlL4d
 nLHzhA0AZLx3wMLuUAHWlACdvMoMtOKKgtoOzQkfXd7ykHdjhWo+SrVzNTinrmZ8TdIm
 0pkSxkUDRBNRG1dUvj+EXxtgytEho6yDJki1omw7+EqTggXv+N2DY22foRw8pYmXQvI0
 72Nw==
X-Gm-Message-State: ACrzQf3LiaIiXG+NUiMOJCXINHKdlmC9Z1cbeJE9/fb+fVtxCM7BFJFZ
 U9ZOWCZy5RGwLAy501bpU++nLABqsNY1VtjPsXc=
X-Google-Smtp-Source: AMsMyM4qdLA3pXE7T0/9S3VG+FTTx1d4MU76Zm/Tdmu4R7/ejjY8ZX0p9w+s2ZXrZvwLf/VXnf884qboPzZIon94SJ0=
X-Received: by 2002:a65:6cc8:0:b0:3fe:2b89:cc00 with SMTP id
 g8-20020a656cc8000000b003fe2b89cc00mr20734704pgw.599.1664208125049; Mon, 26
 Sep 2022 09:02:05 -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>
In-Reply-To: <CACdvm3PyP9yrxx_Yewtx_yQh=i2uwGYj-wtY7HBER1bmG46NEw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 26 Sep 2022 12:01:54 -0400
Message-ID: <CAB3F3Du=+YYKbfgB5LZPnCg40=5YCn_0tkpJ4LO9bMK0U-3wXg@mail.gmail.com>
To: Bastien TEINTURIER <bastien@acinq.fr>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000020403405e996a6d4"
X-Mailman-Approved-At: Mon, 26 Sep 2022 16:46:16 +0000
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: Mon, 26 Sep 2022 16:02:08 -0000

--00000000000020403405e996a6d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 the
transactions as a package, then individually. Not the same, not sure how
different. I'll defer to experts.

Best,
Greg

On Mon, Sep 26, 2022 at 11:48 AM 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 would b=
e
> > 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" a=
n
> > anchor to a specific wallet/user. We can save quite a few bytes by havi=
ng
> > the input be empty of witness data.
> > 2) If we allow for a single dust-value(0 on up) output which is
> immediately
> > spent by 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, if f=
or
> 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 (especial=
ly
> 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 transaction=
.
>>
>> 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 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.
>>
>> 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 replaceme=
nt
>> candidate of size 1000 vb offering 10 sat/vb. It could be argued the for=
mer
>> 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 *latt=
er*
>> making for a utxo considered the best ancestor set. Maybe in the long-te=
rm
>> 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 confirmation=
s
>> of commitment transactions is unsafe, as the counterparty could enter in=
 a
>> "cat-and-mouse" game to replace one of the batch element at each block t=
o
>> 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 poo=
l,
>> as the cost of acquiring UTXO is non-null and in the optimistic case, yo=
u
>> don't need to do unilateral closure. Let's say you close dozens of chann=
els
>> at the same time, a UTXO pool management strategy might be to fan-out th=
e
>> 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, the
>> honest LN node should be able to broadcast a "at least as high ancestor
>> feerate" HTLC-timeout transaction. With `option_anchor_outputs" there is=
 no
>> unconfirmed ancestor to replace, as the commitment transaction, whatever
>> 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. 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...
>>
>> > "Can a V2 transaction replace a V3 transaction and vice versa?"
>>
>> IIUC, a V3 package could replace a V2 package, with the benefit of the
>> new package RBF rules applied. I think this would be a significant
>> advantage for LN, as for the current ~85k of opened channels, the old V2
>> states shouldn't be pinning vectors. Currently, commitment transactions
>> 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 RB=
F
>>> 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 Town=
s,
>>> 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 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 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 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 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 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 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 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 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.
>>>
>>> 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 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 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, 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 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 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 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 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 deploye=
d
>>> 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 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 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 using
>>> 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-September/=
019464.html
>>> [2]:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/01=
9817.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
>

--00000000000020403405e996a6d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Bastien,<div><br></div><div>&gt; This may be already cover=
ed by the current package RBF logic, in that</div>scenario we are simply re=
placing [ParentTx, ChildTx1] with<br>[ParentTx, ChildTx2] that pays more fe=
es, right?<div><br></div><div>For clarification, package RBF is ParentTx*s*=
(plural), and ChildTx(singular), so it might be a bit more complicated than=
 we&#39;re thinking, and currently the V3 proposal would first de-duplicate=
=C2=A0the ParentTx based on what is in the mempool, then look at the &quot;=
rest&quot; of the transactions as a package, then individually. Not the sam=
e, 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 Bastien TEIN=
TURIER via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blo=
ckquote 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">Thanks Glori=
a for this 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 output? What if I need to bump counterparty&#39;s commitment tx in m=
empool?&quot;<br>&gt; You won&#39;t need to fee-bump a counterparty&#39;s c=
ommitment 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 ca=
n also very easily make that single anchor spendable by<br>both participant=
s (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, wh=
ich is quite desirable (your own commitment tx has<br>CSV delays on your ou=
tputs, whereas your counterparty&#39;s commitment tx<br>doesn&#39;t).<br><b=
r>&gt; &quot;Is this a privacy issue, i.e. doesn&#39;t it allow fingerprint=
ing LN<br>transactions based on nVersion?&quot;<br><br>I agree with you, th=
is 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 wo=
uld detect a &quot;sibling output spend&quot;<br>&gt; conflict, and knock i=
t out of the mempool via the other replacement rules?<br>&gt; Getting rid o=
f the requirement to 1 block csv lock every output would be<br>&gt; quite n=
ice from a smart contracting composability point of view.<br><br>+1, that w=
ould be very neat!<br><br>This may be already covered by the current packag=
e RBF logic, in that<br>scenario we are simply replacing [ParentTx, ChildTx=
1] with<br>[ParentTx, ChildTx2] that pays more fees, right?<br><br>&gt; 1) =
I do think that we should seriously consider allowing OP_TRUE to become<br>=
&gt; a standard script type as part of this policy update. If pinning is so=
lved,<br>&gt; then there&#39;s no reason to require all those extra bytes f=
or &quot;binding&quot; an<br>&gt; anchor to a specific wallet/user. We can =
save quite 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 i=
mmediately<br>&gt; spent by the package, anchors become even easier to to d=
esign. No value has<br>&gt; to be &quot;sapped&quot; from contract particip=
ants to make an anchor output. There&#39;s<br>&gt; more complications for t=
his, such as making sure the parent transaction is<br>&gt; dropped if the c=
hild spend is dropped, but maybe it&#39;s worth the squeeze.<br><br>I also =
think both 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 mea=
ns we could end up with 0-value outputs in the utxo set, if for<br>some rea=
son the parent tx is CPFP-ed via another output than the 0-value one,<br>wh=
ich would be a utxo set bloat issue. But I&#39;d argue that we&#39;re proba=
bly<br>already creating utxo set bloat with the 330 sat anchor outputs (esp=
ecially<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>Thank=
s,<br>Bastien</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">Le=C2=A0lun. 26 sept. 2022 =C3=A0=C2=A003:22, Antoine Riard vi=
a bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9cri=
t=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 di=
r=3D"ltr">Hi Gloria,<br><br>Thanks for the progress on package RBF, few ear=
ly questions.<br><br>&gt; 2. Any descendant of an unconfirmed V3 transactio=
n 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 accep=
t such a transaction.<br><br>So I&#39;m not sure if those two rules are com=
patible with miners incentives...<br><br>&gt; 4. A V3 transaction that has =
an unconfirmed V3 ancestor cannot be<br>&gt; =C2=A0 =C2=A0larger than 1000 =
virtual bytes.<br><br>If I understand correctly the 1000 vb upper bound rat=
ional, 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=
 odds to confirm.<br><br>I still wonder if this compatible with miner incen=
tives 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 interestin=
g than a V3 replacement candidate of size 1000 vb offering 10 sat/vb. It co=
uld be argued the former should be conserved.<br><br>(That said, the hard t=
hing with any replacement strategy we might evict a parent transaction *now=
* to which is attached a high-feerate child *latter* making for a utxo cons=
idered the best ancestor set. Maybe in the long-term miners should keep eve=
ry transaction 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, only allowing the V3 child to have<br>&gt; 2 inputs would require =
L2 protocols to manage a wallet with high-value<br>&gt; UTXOs and make batc=
hed fee-bumping impossible. However, as the<br>&gt; fee-bumping child only =
needs to fund fees (as opposed to payments),<br>&gt; just a few UTXOs shoul=
d suffice.<br><br>Reminder for L2 devs, batched fee-bumping of time-sensiti=
ve confirmations 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 t=
he batch, I think.<br><br>On the other hand, I wonder if we wouldn&#39;t wa=
nt 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&#39;t need to do unilateral closure. Let&#39;s say=
 you close dozens of channels at the same time, a UTXO pool management stra=
tegy 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 un=
confirmed inputs was<br>&gt; originally &quot;A package may include new unc=
onfirmed inputs, but the<br>&gt; ancestor feerate of the child must be at l=
east as high as the ancestor<br>&gt; feerates of every transaction being re=
placed.&quot;<br><br>Note, I think we would like this new RBF rule to also =
apply to single transaction package, e.g second-stage HTLC transactions, wh=
ere a counterparty pins a HTLC-preimage by abusing rule 3. In that case, th=
e honest LN node should be able to broadcast a &quot;at least as high ances=
tor feerate&quot; HTLC-timeout transaction. With `option_anchor_outputs&quo=
t; there is no unconfirmed ancestor to replace, as the commitment transacti=
on, 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 finge=
rprinting LN<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-de=
fined 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;l=
l always have tricky fingerprints leaking from unilateral LN closures such =
as HTLC/PTLC timelocks...<br><br>&gt; &quot;Can a V2 transaction replace a =
V3 transaction and vice versa?&quot;<br><br>IIUC, a V3 package could replac=
e a V2 package, with the benefit of the new package RBF rules applied. I th=
ink this would be a significant advantage for LN, as for the current ~85k o=
f opened channels, the old V2 states shouldn&#39;t be pinning vectors. Curr=
ently, commitment transactions signal replaceability.<br></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 23 se=
pt. 2022 =C3=A0=C2=A011:26, Gloria Zhao via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote cla=
ss=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>p=
olicies intended to aid L2/contract protocols. I realized that<br>the previ=
ously proposed Package Mempool Accept package RBF [1]<br><div>had a few rem=
aining problems after digging into the RBF logic more [2].</div><div>This a=
dditional set of policies solves them without requiring a huge RBF overhaul=
.<br></div><br>I&#39;ve written an implementation (and docs) for Bitcoin Co=
re:<br><a href=3D"https://github.com/bitcoin/bitcoin/pull/25038" target=3D"=
_blank">https://github.com/bitcoin/bitcoin/pull/25038</a><br><br>(You may n=
otice that this proposal incorporates feedback on the PR - thanks Suhas Daf=
tuar, Gregory Sanders, Bastien Teinturier, Anthony Towns, and others.)<br><=
br>If you are interested in using package RBF/relay to bump presigned<br>tr=
ansactions, I think you may be interested in reviewing this proposal.<br>Th=
is should solve Rule 3 pinning and perhaps allow us<br>to get rid of CPFP c=
arve-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=
 or something that makes it unusable for you, I would<br>really really like=
 to know.<br><br>Note that transactions with nVersion=3D3 (&quot;V3 transac=
tions&quot;) are<br>currently non-standard in Bitcoin Core. That means **an=
ything that was<br>standard before this policy change would still be standa=
rd<br>afterwards.** If you don&#39;t want your transactions to be subject t=
o<br>these rules, just continue whatever you&#39;re doing and don&#39;t use=
<br>nVersion=3D3. AFAICT this shouldn&#39;t break anything, but let me know=
 if<br>this would be disruptive for you?<br><br>**New Policies:**<br><br>Th=
is includes:<br>- a set of additional policy rules applying to V3 transacti=
ons<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>sta=
ndard output types, cleanstack, etc.). The following additional<br>rules ap=
ply to V3:<br><br>1. A V3 transaction can be replaced, 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 de=
scendant of an unconfirmed V3 transaction must also be V3.<br><br>*Rational=
e*: Combined with Rule 1, this gives us the property of<br>&quot;inherited&=
quot; replaceability signaling when descendants of unconfirmed<br>transacti=
ons are created. Additionally, checking whether a transaction<br>signals re=
placeability this way does not require mempool traversal,<br>and does not c=
hange based on what transactions are mined. It also<br>makes subsequent rul=
es about descendant limits much easier to check.<br><br>*Note*: The descend=
ant of a *confirmed* V3 transaction does not need to be V3.<br><br>3. An un=
confirmed V3 transaction cannot have more than 1 descendant.<br><br>*Ration=
ale*: (Upper bound) the larger the descendant limit, the more<br>transactio=
ns 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=
 adding 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>pr=
esigned transaction. The contract protocol can create presigned<br>transact=
ions paying 0 fees and 1 output for attaching a CPFP at<br>broadcast time (=
&quot;anchor output&quot;). Without package RBF, multiple anchor<br>outputs=
 would be required to allow each counterparty to fee-bump any<br>presigned =
transaction. With package RBF, since the presigned<br>transactions can repl=
ace each other, 1 anchor output is sufficient.<br><br>4. A V3 transaction t=
hat has an unconfirmed V3 ancestor cannot be<br>=C2=A0 =C2=A0larger than 10=
00 virtual bytes.<br><br>*Rationale*: (Upper bound) the larger the descenda=
nt size limit, the<br>more vbytes may need to be replaced. With default lim=
its, if the child<br>is e.g. 100,000vB, that might be an additional 100,000=
sats (at<br>1sat/vbyte) or more, depending on the feerate.<br><br>(Lower bo=
und) the smaller this limit, the fewer UTXOs a child may use<br>to fund thi=
s fee-bump. For example, only allowing the V3 child to have<br>2 inputs wou=
ld require L2 protocols to manage a wallet with high-value<br>UTXOs and mak=
e 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 su=
ffice.<br><br>With a limit of 1000 virtual bytes, depending on the output t=
ypes, the<br>child can have 6-15 UTXOs, which should be enough to fund a fe=
e-bump<br>without requiring a carefully-managed UTXO pool. With 1000 virtua=
l<br>bytes as the descendant limit, the cost to replace a V3 transaction<br=
>has much lower variance.<br><br>*Rationale*: This makes the rule very easi=
ly &quot;tacked on&quot; to existing<br>logic for policy and wallets. A tra=
nsaction may be up to 100KvB on its<br>own (`MAX_STANDARD_TX_WEIGHT`) and 1=
01KvB with descendants<br>(`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an exis=
ting V3 transaction<br>in the mempool is 100KvB, its descendant can only be=
 1000vB, 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 =
package may include new unconfirmed inputs, but the<br>ancestor feerate of =
the child must be at least as high as the ancestor<br>feerates of every tra=
nsaction being replaced.&quot;<br><br>The package may still include new unc=
onfirmed inputs. However,<br>the new rule is modified to be &quot;The minim=
um between package feerate<br>and ancestor feerate of the child is not lowe=
r than the individual<br>feerates of all directly conflicting transactions =
and the ancestor<br>feerates of all original transactions.&quot;<br><br>*Ra=
tionale*: We are attempting to ensure that the replacement<br>transactions =
are not less incentive-compatible to mine. However, a<br>package/transactio=
n&#39;s ancestor feerate is not perfectly representative<br>of its incentiv=
e compatibility; it may overestimate (some subset of<br>the ancestors could=
 be included by itself if it has other high-feerate<br>descendants or are t=
hemselves higher feerate than this<br>package/transaction). Instead, we use=
 the minimum between the package<br>feerate and ancestor feerate of the chi=
ld as a more conservative value<br>than what was proposed originally.<br><b=
r>2. A new rule is added, requiring that all package transactions with<br>m=
empool conflicts to be V3. This also means the &quot;sponsoring&quot;<br>ch=
ild transaction must be V3.<br><br>*Note*: Combined with the V3 rules, this=
 means the package must be<br>a child-with-parents package. Since package v=
alidation is only<br>attempted if the transactions do not pay sufficient fe=
es to be<br>accepted on their own, this effectively means that only V3<br>t=
ransactions 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 economically rational for<br>ancestor=
 packages, but not necessarily other types of packages.<br>A child-with-par=
ents 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>harder to see that we&#39;re ap=
plying the descendant limits correctly if<br>the package has a gnarly, many=
-generation, 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 =
sponsee.<br><br>Please see doc/policy/version3_transactions.md and<br>doc/p=
olicy/packages.md in the PR for the full set of rules.<br><br>**Intended us=
age for LN:**<br><br>Commitment transactions should be V3 and have 1 anchor=
 output. They<br>can be signed with 0 fees (or 1sat/vbyte) once package rel=
ay is deployed<br>on a significant portion of the network. If the commitmen=
t tx must<br>be broadcast, determine the desired feerate at broadcast time =
and<br>spend the anchor output in a high feerate transaction. I&#39;m going=
 to<br>call the broadcasted commitment tx &quot;the parent&quot; and the at=
tached<br>fee-bumping tx &quot;the child.&quot;<br><br>- This child must be=
 V3.<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>

--00000000000020403405e996a6d4--