path: root/95/ba3a37797c963b6a49b67734e763e0a822fa57

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CEE48C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Nov 2022 15:32:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 87E2B4009E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Nov 2022 15:32:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 87E2B4009E
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=qdwuOCKE
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level: 
X-Spam-Status: No, score=-1.838 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, T_KAM_HTML_FONT_INVALID=0.01]
 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 b71ihJ0BK7r8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Nov 2022 15:32:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8C7FC4013E
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [IPv6:2a00:1450:4864:20::635])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 8C7FC4013E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Nov 2022 15:32:51 +0000 (UTC)
Received: by mail-ej1-x635.google.com with SMTP id td2so28120778ejc.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Nov 2022 07:32:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=/r7Os/HDqhe4tkSBT2j/kFlHASgGvg/3xOUCB4A0vcg=;
 b=qdwuOCKEWDYVBGezXyiBafNRP/nQ3rtPDlPRy+CfZH7YTHDu6EJLScVzucwVMK1J0x
 AtdboGtddnJstJqLStwc8AlDNiiQc233hTXREPHIqSQDndxhlpcT1b3qwvcIn6YwHxUT
 3iJWiY3vTuyXSdGssN9vAAdG6iL3guL+vaGphK2kgdbb0eNQCkwVZcNxG/JZ2v4OaVPv
 sTEuha9vjc2Qme6R77nHKCbMqGTvgvbIaNyWSS/XxxiEiFSSppkFF+WnU5djHfromXCG
 sSZgK7DuWAGs/2mEnT//9JGlhRiGn2g4kQrYKUQ3FNkzzn36mVoOx1HUIwYDpwVukUDB
 L9dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=/r7Os/HDqhe4tkSBT2j/kFlHASgGvg/3xOUCB4A0vcg=;
 b=XR+3jX8rLiE71thDhs9IuhzZy6LdRNH8/3B41nlGtuO3g5yksPfXR2hkJuGt/Tfdpm
 eIjGtACUIl7yhSs/5XR7TYSU8aC/ba/khxgLdQdxDPaiZf+mh44DNAX29Nm00IWV+WOn
 86KcwWDQiPePGLP9pWVEbhQ/Lq+JaRkFBadvK7RxoPqA4Bux/pFFHCcLHWiRR9gb+Cy5
 0ILB5uYkF8jWACHtPqUw+30ged3pTcOP09R/CQWiT/7M2HDb2P76ddFRnMjCTzzaYKtQ
 gIsHCA3VWTIWuolWj/YM8BrSiFyQNZysaswwRDxA7MUt6tCnlwBYhVcdVT6KAB8T79MU
 Fkqg==
X-Gm-Message-State: ANoB5pkAn5KGuUnDdAT7W0mLCpnrwc8Gwd7YFrGa6xNZkKjOon9qfFzM
 l00Ig+Rj1wdaaT1InK1RGONhreJhgWEU1GQHb/d3PsYoNBU=
X-Google-Smtp-Source: AA0mqf4ng0Aunii5zh4CTHfY9rLMuRqs88EyLRSVoGjFLXqtjPiZudgJdmXx5yMJW8KmGFgMte4nezJQSZNWpZjbjnM=
X-Received: by 2002:a17:906:4e04:b0:78d:9b4f:44ee with SMTP id
 z4-20020a1709064e0400b0078d9b4f44eemr35896185eju.679.1669822369234; Wed, 30
 Nov 2022 07:32:49 -0800 (PST)
MIME-Version: 1.0
References: <CAB3F3Dukoz3P3Ne7tCxMiwwAGm3Fv8r_fUkNbGAtGhAZDYDgCQ@mail.gmail.com>
 <ec952a9c-d810-4996-9ca9-1e9c6f6faca4@app.fastmail.com>
 <CAB3F3DvH3FnK8krykbcRVKc-z8F4yjt9mzYHevpYxaWkH4w9tw@mail.gmail.com>
 <CAD5xwhgFBQ-ScyBU5=WnREGsN-T=Nv=oR6vOsnHJ-ZMzDF8Vqg@mail.gmail.com>
 <CAPfvXf+N8aF+bqjGzpfDrhCYg7ngciSDCpUnCMHD+k5F+m3oWA@mail.gmail.com>
 <CAB3F3DuDODUxB5aK4VFWa8sKFCkZfOj6Vjb+Wp39opyt8MNnEA@mail.gmail.com>
In-Reply-To: <CAB3F3DuDODUxB5aK4VFWa8sKFCkZfOj6Vjb+Wp39opyt8MNnEA@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 30 Nov 2022 10:32:36 -0500
Message-ID: <CAB3F3DtrSFPmperGJJAUDZj7vt9aHgvkc0b5Pts3+mq5fTuWXA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002804ca05eeb1d1b2"
Subject: Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF
 againstpackage limit pinning
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: Wed, 30 Nov 2022 15:32:55 -0000

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

Small update.

A bit ago I went ahead and implemented ephemeral anchors on top of the V3
proposal to see what the complexity looks like:
https://github.com/bitcoin/bitcoin/pull/26403

Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not camp
the value that is used elsewhere.

Please let me know if you have any early feedback on this!

Greg

On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders <gsanders87@gmail.com> wrote:

> So it doesn't look like I'm ignoring a good question:
>
> No solid noninteractive ideas, unless we get some very flexible sighash
> softfork. Interactively, I think you can get collaborative fee bumps unde=
r
> the current consensus regime and ephemeral anchors. The child will just b=
e
> built with inputs from different people.
>
> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne <james.obeirne@gmail.com>
> wrote:
>
>> I'm also very happy to see this proposal, since it gets us closer to
>> having a mechanism that allows the contribution to feerate in an
>> "unauthenticated" way, which seems to be a very helpful feature for vaul=
ts
>> and other contracting protocols.
>>
>> One possible advantage of the sponsors interface -- and I'm curious for
>> your input here Greg -- is that with sponsors, assuming we relaxed the "=
one
>> sponsor per sponsoree" constraint, multiple uncoordinated parties can
>> collaboratively bump a tx's feerate. A simple example would be a batch
>> withdrawal from an exchange could be created with a low feerate, and the=
n
>> multiple users with a vested interest of expedited confirmation could al=
l
>> "chip in" to raise the feerate with multiple sponsor transactions.
>>
>> Having a single ephemeral output seems to create a situation where a
>> single UTXO has to shoulder the burden of CPFPing a package. Is there so=
me
>> way we could (possibly later) amend the ephemeral anchor interface to al=
low
>> for this kind of collaborative sponsoring? Could you maybe see "chained"
>> ephemeral anchors that would allow this?
>>
>>
>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Excellent proposal and I agree it does capture much of the spirit of
>>> sponsors w.r.t. how they might be used for V3 protocols.
>>>
>>> The only drawbacks I see is they don't work for lower tx version
>>> contracts, so there's still something to be desired there, and that the
>>> requirement to sweep the output must be incentive compatible for the mi=
ner,
>>> or else they won't enforce it (pass the buck onto the future bitcoiners=
).
>>> The Ephemeral UTXO concept can be a consensus rule (see
>>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>>> UTXO") we add later on in lieu of managing them by incentive, so maybe =
it's
>>> a cleanup one can punt.
>>>
>>> One question I have is if V3 is designed for lightning, and this is
>>> designed for lightning, is there any sense in requiring these outputs f=
or
>>> v3? That might help with e.g. anonymity set, as well as potentially kee=
p
>>> the v3 surface smaller.
>>>
>>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> > does that effectively mark output B as unspendable once the child
>>>> gets confirmed?
>>>>
>>>> Not at all. It's a normal spend like before, since the parent has been
>>>> confirmed. It's completely unrestricted, not being bound to any
>>>> V3/ephemeral anchor restrictions on size, version, etc.
>>>>
>>>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> Thank you very much for sharing your proposal!
>>>>>
>>>>> I think there's one thing about the second part of your proposal that
>>>>> I'm missing. Specifically, assuming the scenario of a v3 transaction =
with
>>>>> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
>>>>> transaction spends A and OP_TRUE, does that effectively mark output B=
 as
>>>>> unspendable once the child gets confirmed? If so, isn't the implicati=
on
>>>>> therefore that to safely spend a transaction with an ephemeral anchor=
, all
>>>>> outputs must be spent? Thanks!
>>>>>
>>>>> Best,
>>>>> Arik
>>>>>
>>>>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>>>>>
>>>>> Hello Everyone,
>>>>>
>>>>> Following up on the "V3 Transaction" discussion here
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septembe=
r/020937.html
>>>>> , I would like to elaborate a bit further on some potential follow-on=
 work
>>>>> that would make pinning severely constrained in many setups].
>>>>>
>>>>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks
>>>>> under some constraints[0]. This means that when a replacement is to b=
e made
>>>>> and propagated, it costs the expected amount of fees to do so. This i=
s a
>>>>> great start. What's left in this subset of pinning is *package limit*
>>>>> pinning. In other words, a fee-paying transaction cannot enter the me=
mpool
>>>>> due to the existing mempool package it is being added to already bein=
g too
>>>>> large in count or vsize.
>>>>>
>>>>> Zooming into the V3 simplified scenario for sake of discussion, thoug=
h
>>>>> this problem exists in general today:
>>>>>
>>>>> V3 transactions restrict the package limit of a V3 package to one
>>>>> parent and one child. If the parent transaction includes two outputs =
which
>>>>> can be immediately spent by separate parties, this allows one party t=
o
>>>>> disallow a spend from the other. In Gloria's proposal for ln-penalty,=
 this
>>>>> is worked around by reducing the number of anchors per commitment
>>>>> transaction to 1, and each version of the commitment transaction has =
a
>>>>> unique party's key on it. The honest participant can spend their vers=
ion
>>>>> with their anchor and package RBF the other commitment transaction sa=
fely.
>>>>>
>>>>> What if there's only one version of the commitment transaction, such
>>>>> as in other protocols like duplex payment channels, eltoo? What about=
 multi
>>>>> party payments?
>>>>>
>>>>> In the package RBF proposal, if the parent transaction is identical t=
o
>>>>> an existing transaction in the mempool, the parent will be detected a=
nd
>>>>> removed from the package proposal. You are then left with a single V3=
 child
>>>>> transaction, which is then proposed for entry into the mempool. In th=
e case
>>>>> of another parent output already being spent, this is simply rejected=
,
>>>>> regardless of feerate of the new child.
>>>>>
>>>>> I have two proposed solutions, of which I strongly prefer the latter:
>>>>>
>>>>> 1) Expand a carveout for "sibling eviction", where if the new child i=
s
>>>>> paying "enough" to bump spends from the same parent, it knocks its si=
bling
>>>>> out of the mempool and takes the one child slot. This would solve it,=
 but
>>>>> is a new eviction paradigm that would need to be carefully worked thr=
ough.
>>>>>
>>>>> 2) Ephemeral Anchors (my real policy-only proposal)
>>>>>
>>>>> Ephemeral Anchors is a term which means an output is watermarked as a=
n
>>>>> output that MUST be spent in a V3 package. We mark this anchor by bei=
ng the
>>>>> bare script `OP_TRUE` and of course make these outputs standard to re=
lay
>>>>> and spend with empty witness data.
>>>>>
>>>>> Also as a simplifying assumption, we require the parent transaction
>>>>> with such an output to be 0-fee. This makes mempool reasoning simpler=
 in
>>>>> case the child-spend is somehow evicted, guaranteeing the parent will=
 be as
>>>>> well.
>>>>>
>>>>> Implications:
>>>>>
>>>>> a) If the ephemeral anchor MUST be spent, we can allow *any* value,
>>>>> even dust, even 0, without worrying about bloating the utxo set. We r=
elax
>>>>> this policy for maximum smart contract flexibility and specification
>>>>> simplicity..
>>>>>
>>>>> b) Since this anchor MUST be spent, any spending of other outputs in
>>>>> the same parent transaction MUST directly double-spend prior spends o=
f the
>>>>> ephemeral anchor. This causes the 1 block CSV timelock on outputs to =
be
>>>>> removed in these situations. This greatly magnifies composability of =
smart
>>>>> contracts, as now we can do things like safely splice directly into n=
ew
>>>>> channels, into statechains, your custodial wallet account, your cold
>>>>> wallet, wherever, without requiring other wallets to support arbitrar=
y
>>>>> scripts. Also it hurts that 1 CSV time locked scripts may not be mini=
script
>>>>> compatible to begin with...
>>>>>
>>>>> c) *Anyone* can bump the transaction, without any transaction key
>>>>> material. This is essentially achieving Jeremy's Transaction Sponsors=
 (
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Septembe=
r/018168.html)
>>>>> proposal without consensus changes. As long as someone gets a fully s=
igned
>>>>> parent, they can execute a bump with minimal wallet tooling. If a
>>>>> transaction author doesn=E2=80=99t want a =E2=80=9Csponsor=E2=80=9D, =
do not include the output.
>>>>>
>>>>> d) Lightning Carve-out(
>>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Octobe=
r/002240.html)
>>>>> is superseded by this logic, as we are not restricted to two immediat=
ely
>>>>> spendable output scenarios. In its place, robust multi-party fee bump=
ing is
>>>>> possible.
>>>>>
>>>>> e) This also benefits more traditional wallet scenarios, as change
>>>>> outputs can no longer be pinned, and RBF/CPFP becomes robust. Payees =
in
>>>>> simple spends cannot pin you. Batched payouts become a lot less painf=
ul.
>>>>> This was one of the motivating use cases that created the term =E2=80=
=9Cpinning=E2=80=9D in
>>>>> the first place(
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February=
/015717.html),
>>>>> even if LN/L2 discussion has largely overtaken it due to HTLC theft r=
isks.
>>>>>
>>>>> Open Question(s):
>>>>>
>>>>>
>>>>>    1.
>>>>>
>>>>>    If we allow non-zero value in ephemeral outputs, does this open up
>>>>>    a MEV we are worried about? Wallets should toss all the value dire=
ctly to
>>>>>    fees, and add their own additional fees on top, otherwise miners h=
ave
>>>>>    incentive to make the smallest utxo burn transaction to claim thos=
e funds.
>>>>>    They just confirmed your parent transaction anyways, so do we care=
?
>>>>>    2.
>>>>>
>>>>>    SIGHASH_GROUP like constructs would allow uncommitted ephemeral
>>>>>    anchors to be added at spend time, depending on spending requireme=
nts.
>>>>>    SIGHASH_SINGLE already allows this.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hopefully this gives people something to consider as we move forward
>>>>> in thinking about mempool design within the constraints we have today=
.
>>>>>
>>>>>
>>>>> Greg
>>>>>
>>>>> 0: With V3 transactions where you have "veto power" over all the
>>>>> inputs in that transaction. Therefore something like ANYONECANPAY is =
still
>>>>> broken. We need a more complex solution, which I=E2=80=99m punting fo=
r the sake of
>>>>> progress.
>>>>> _______________________________________________
>>>>> 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
>>>
>>

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

<div dir=3D"ltr"><div>Small update.</div><div><br></div>A bit ago I went ah=
ead and implemented ephemeral anchors on top of the V3 proposal to see what=
 the complexity looks like:=C2=A0<a href=3D"https://github.com/bitcoin/bitc=
oin/pull/26403">https://github.com/bitcoin/bitcoin/pull/26403</a><div><br><=
/div><div>Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to=
 not camp the value that is used elsewhere.</div><div><br></div><div>Please=
 let me know if you have any early feedback on this!</div><div><br></div><d=
iv>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders &lt;<a href=3D"ma=
ilto:gsanders87@gmail.com">gsanders87@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">So it doesn=
&#39;t look like I&#39;m ignoring a good question:<div><br></div><div>No so=
lid noninteractive ideas, unless we get some very flexible sighash softfork=
. Interactively, I think you can get collaborative fee bumps under the curr=
ent consensus regime and ephemeral=C2=A0anchors. The child will just be bui=
lt with inputs from different people.</div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 19, 2022 at 11:12 AM=
 James O&#39;Beirne &lt;<a href=3D"mailto:james.obeirne@gmail.com" target=
=3D"_blank">james.obeirne@gmail.com</a>&gt; wrote:<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"><div>I&#39;m also very =
happy to see this proposal, since it gets us closer to having a mechanism t=
hat allows the contribution to  feerate in an &quot;unauthenticated&quot; w=
ay, which seems to be a very helpful feature for vaults and other contracti=
ng protocols.</div><div><br></div><div>One possible advantage of the sponso=
rs interface -- and I&#39;m curious for your input here Greg -- is that wit=
h sponsors, assuming we relaxed the &quot;one sponsor per sponsoree&quot; c=
onstraint, multiple uncoordinated parties can collaboratively bump a tx&#39=
;s feerate. A simple example would be a batch withdrawal from an exchange c=
ould be created with a low feerate, and then multiple users with a vested i=
nterest of expedited confirmation could all &quot;chip in&quot; to raise th=
e feerate with multiple sponsor transactions. <br></div><div><br></div><div=
>Having a single ephemeral output seems to create a situation where a singl=
e UTXO has to shoulder the burden of CPFPing a package. Is there some way w=
e could (possibly later) amend the ephemeral anchor interface to allow for =
this kind of collaborative sponsoring? Could you maybe see &quot;chained&qu=
ot; ephemeral anchors that would allow this?<br></div><div><br></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue=
, Oct 18, 2022 at 12:52 PM Jeremy Rubin 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; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">Excellent proposal and I agree it does capture much of the spirit of spon=
sors w.r.t. how they might be used for V3 protocols.</div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The only d=
rawbacks I see=C2=A0is they don&#39;t work for lower tx version contracts, =
so there&#39;s still something to be desired there, and that the requiremen=
t to sweep the output must be incentive compatible for the miner, or else t=
hey won&#39;t enforce it (pass the buck onto the future bitcoiners). The Ep=
hemeral UTXO concept can be a consensus rule (see=C2=A0<a href=3D"https://r=
ubin.io/public/pdfs/multi-txn-contracts.pdf" target=3D"_blank">https://rubi=
n.io/public/pdfs/multi-txn-contracts.pdf</a> &quot;Intermediate UTXO&quot;)=
 we add later on in lieu of managing them by incentive, so maybe it&#39;s a=
 cleanup one can punt.</div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)">One question I have is if V3 is designed=
 for lightning, and this is designed for lightning, is there any sense in r=
equiring these outputs for v3? That might help with e.g. anonymity set, as =
well as potentially keep the v3 surface smaller.</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 18, 2022=
 at 11:51 AM Greg Sanders via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.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);padding-le=
ft:1ex"><div dir=3D"ltr">&gt; does that effectively mark output B as unspen=
dable once the child gets confirmed?<div><br></div><div>Not at all. It&#39;=
s a normal spend like before, since the parent has been confirmed. It&#39;s=
 completely unrestricted, not being bound to any V3/ephemeral anchor restri=
ctions on size, version, etc.</div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 18, 2022 at 11:47 AM Arik So=
sman via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<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><u></u><=
div><div>Hi Greg,<br></div><div><br></div><div>Thank you very much for shar=
ing your proposal!</div><div><br></div><div>I think there&#39;s one thing a=
bout the second part of your proposal that I&#39;m missing. Specifically, a=
ssuming the scenario of a v3 transaction with three outputs, A, B, and the =
ephemeral anchor OP_TRUE. If a child transaction spends A and OP_TRUE, does=
 that effectively mark output B as unspendable once the child gets confirme=
d? If so, isn&#39;t the implication therefore that to safely spend a transa=
ction with an ephemeral anchor, all outputs must be spent? Thanks!<br></div=
><div><br></div><div>Best,<br></div><div>Arik</div><div><br></div><div>On T=
ue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:<br></div>=
<blockquote type=3D"cite" id=3D"m_7916680740001169827m_-7137361365701771057=
m_5142274361577099701m_8177486709224577946m_-7024055043742391057m_436808606=
5316228638qt"><div dir=3D"ltr"><span id=3D"m_7916680740001169827m_-71373613=
65701771057m_5142274361577099701m_8177486709224577946m_-7024055043742391057=
m_4368086065316228638qt-gmail-docs-internal-guid-2d3e64aa-7fff-66f1-ed3d-c9=
4d5a1f62c6"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-=
bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:transparent;fo=
nt-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:bas=
eline;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=
=3D"font-size:11pt">Hello Everyone,</span></span></span><br></p><div><br></=
div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0=
pt"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-varia=
nt-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;wh=
ite-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-s=
ize:11pt">Following up on the &quot;V3 Transaction&quot; discussion here <a=
 href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septe=
mber/020937.html" target=3D"_blank">https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2022-September/020937.html</a> , I would like to elaborate=
 a bit further on some potential follow-on work that would make pinning sev=
erely constrained in many setups].</span></span></span><br></p><div><br></d=
iv><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0p=
t"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-varian=
t-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;whi=
te-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-si=
ze:11pt">V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks=
 under some constraints[0]. This means that when a replacement is to be mad=
e and propagated, it costs the expected amount of fees to do so. This is a =
great start. What&#39;s left in this subset of pinning is *package limit* p=
inning. In other words, a fee-paying transaction cannot enter the mempool d=
ue to the existing mempool package it is being added to already being too l=
arge in count or vsize.</span></span></span><br></p><div><br></div><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-numeric=
:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:=
pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">=
Zooming into the V3 simplified scenario for sake of discussion, though this=
 problem exists in general today:</span></span></span><br></p><div><br></di=
v><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt=
"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant=
-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;whit=
e-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-siz=
e:11pt">V3 transactions restrict the package limit of a V3 package to one p=
arent and one child. If the parent transaction includes two outputs which c=
an be immediately spent by separate parties, this allows one party to disal=
low a spend from the other. In Gloria&#39;s proposal for ln-penalty, this i=
s worked around by reducing the number of anchors per commitment transactio=
n to 1, and each version of the commitment transaction has a unique party&#=
39;s key on it. The honest participant can spend their version with their a=
nchor and package RBF the other commitment transaction safely.</span></span=
></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;mar=
gin-top:0pt;margin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-c=
olor:transparent;font-variant-numeric:normal;font-variant-east-asian:normal=
;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-family:A=
rial"><span style=3D"font-size:11pt">What if there&#39;s only one version o=
f the commitment transaction, such as in other protocols like duplex paymen=
t channels, eltoo? What about multi party payments?</span></span></span><br=
></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt=
;margin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:transp=
arent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-a=
lign:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><span=
 style=3D"font-size:11pt">In the package RBF proposal, if the parent transa=
ction is identical to an existing transaction in the mempool, the parent wi=
ll be detected and removed from the package proposal. You are then left wit=
h a single V3 child transaction, which is then proposed for entry into the =
mempool. In the case of another parent output already being spent, this is =
simply rejected, regardless of feerate of the new child.</span></span></spa=
n><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:t=
ransparent;font-variant-numeric:normal;font-variant-east-asian:normal;verti=
cal-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial">=
<span style=3D"font-size:11pt">I have two proposed solutions, of which I st=
rongly prefer the latter:</span></span></span><br></p><div><br></div><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-numeric=
:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:=
pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">=
1) Expand a carveout for &quot;sibling eviction&quot;, where if the new chi=
ld is paying &quot;enough&quot; to bump spends from the same parent, it kno=
cks its sibling out of the mempool and takes the one child slot. This would=
 solve it, but is a new eviction paradigm that would need to be carefully w=
orked through.</span></span></span><br></p><div><br></div><p dir=3D"ltr" st=
yle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"co=
lor:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;fon=
t-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><=
span style=3D"font-family:Arial"><span style=3D"font-size:11pt">2) Ephemera=
l Anchors (my real policy-only proposal)</span></span></span><br></p><div><=
br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bot=
tom:0pt"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-=
variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseli=
ne;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"f=
ont-size:11pt">Ephemeral Anchors is a term which means an output is waterma=
rked as an output that MUST be spent in a V3 package. We mark this anchor b=
y being the bare script `OP_TRUE` and of course make these outputs standard=
 to relay and spend with empty witness data.</span></span></span><br></p><d=
iv><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin=
-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:transparent;f=
ont-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:ba=
seline;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=
=3D"font-size:11pt">Also as a simplifying assumption, we require the parent=
 transaction with such an output to be 0-fee. This makes mempool reasoning =
simpler in case the child-spend is somehow evicted, guaranteeing the parent=
 will be as well.</span></span></span><br></p><div><br></div><p dir=3D"ltr"=
 style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D=
"color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;=
font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap=
"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">Implicat=
ions:</span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"li=
ne-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"color:rgb(0=
,0,0);background-color:transparent;font-variant-numeric:normal;font-variant=
-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><span styl=
e=3D"font-family:Arial"><span style=3D"font-size:11pt">a) If the ephemeral =
anchor MUST be spent, we can allow *any* value, even dust, even 0, without =
worrying about bloating the utxo set. We relax this policy for maximum smar=
t contract flexibility and specification simplicity..</span></span></span><=
br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0=
pt;margin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:tran=
sparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical=
-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><sp=
an style=3D"font-size:11pt">b) Since this anchor MUST be spent, any spendin=
g of other outputs in the same parent transaction MUST directly double-spen=
d prior spends of the ephemeral anchor. This causes the 1 block CSV timeloc=
k on outputs to be removed in these situations. This greatly magnifies comp=
osability of smart contracts, as now we can do things like safely splice di=
rectly into new channels, into statechains, your custodial wallet account, =
your cold wallet, wherever, without requiring other wallets to support arbi=
trary scripts. Also it hurts that 1 CSV time locked scripts may not be mini=
script compatible to begin with...</span></span></span><br></p><div><br></d=
iv><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0p=
t"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-varian=
t-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;whi=
te-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-si=
ze:11pt">c) *Anyone* can bump the transaction, without any transaction key =
material. This is essentially achieving Jeremy&#39;s Transaction Sponsors (=
</span></span></span><a href=3D"https://lists.linuxfoundation.org/pipermail=
/bitcoin-dev/2020-September/018168.html" style=3D"text-decoration-line:none=
" target=3D"_blank"><span style=3D"background-color:transparent;font-varian=
t-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underl=
ine;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-famil=
y:Arial"><span style=3D"font-size:11pt">https://lists.linuxfoundation.org/p=
ipermail/bitcoin-dev/2020-September/018168.html</span></span></span></a><sp=
an style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-nume=
ric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-spa=
ce:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:11p=
t">) proposal without consensus changes. As long as someone gets a fully si=
gned parent, they can execute a bump with minimal wallet tooling. If a tran=
saction author doesn=E2=80=99t want a =E2=80=9Csponsor=E2=80=9D, do not inc=
lude the output.</span></span></span><br></p><div><br></div><p dir=3D"ltr" =
style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"=
color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;f=
ont-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"=
><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">d) Lightn=
ing Carve-out(</span></span></span><a href=3D"https://lists.linuxfoundation=
.org/pipermail/lightning-dev/2019-October/002240.html" style=3D"text-decora=
tion-line:none" target=3D"_blank"><span style=3D"background-color:transpare=
nt;font-variant-numeric:normal;font-variant-east-asian:normal;text-decorati=
on-line:underline;vertical-align:baseline;white-space:pre-wrap"><span style=
=3D"font-family:Arial"><span style=3D"font-size:11pt">https://lists.linuxfo=
undation.org/pipermail/lightning-dev/2019-October/002240.html</span></span>=
</span></a><span style=3D"color:rgb(0,0,0);background-color:transparent;fon=
t-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:base=
line;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D=
"font-size:11pt">)=C2=A0 is superseded by this logic, as we are not restric=
ted to two immediately spendable output scenarios. In its place, robust mul=
ti-party fee bumping is possible.</span></span></span><br></p><div><br></di=
v><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt=
"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant=
-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;whit=
e-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-siz=
e:11pt">e) This also benefits more traditional wallet scenarios, as change =
outputs can no longer be pinned, and RBF/CPFP becomes robust. Payees in sim=
ple spends cannot pin you. Batched payouts become a lot less painful. This =
was one of the motivating use cases that created the term =E2=80=9Cpinning=
=E2=80=9D in the first place(</span></span></span><a href=3D"https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html" style=
=3D"text-decoration-line:none" target=3D"_blank"><span style=3D"background-=
color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma=
l;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wr=
ap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html=
</span></span></span></a><span style=3D"color:rgb(0,0,0);background-color:t=
ransparent;font-variant-numeric:normal;font-variant-east-asian:normal;verti=
cal-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial">=
<span style=3D"font-size:11pt">), even if LN/L2 discussion has largely over=
taken it due to HTLC theft risks.</span></span></span><br></p><div><br></di=
v><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt=
"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant=
-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;whit=
e-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-siz=
e:11pt">Open Question(s):</span></span></span><br></p><div><br></div><ol st=
yle=3D"margin-top:0px;margin-bottom:0px"><li dir=3D"ltr" style=3D"list-styl=
e-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" style=3D"li=
ne-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation"><spa=
n style=3D"background-color:transparent;font-variant-numeric:normal;font-va=
riant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><span=
 style=3D"font-size:11pt">If we allow non-zero value in ephemeral outputs, =
does this open up a MEV we are worried about? Wallets should toss all the v=
alue directly to fees, and add their own additional fees on top, otherwise =
miners have incentive to make the smallest utxo burn transaction to claim t=
hose funds. They just confirmed your parent transaction anyways, so do we c=
are?</span></span><br></p></li><li dir=3D"ltr" style=3D"list-style-type:dec=
imal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:tra=
nsparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertica=
l-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:=
1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation"><span style=3D=
"background-color:transparent;font-variant-numeric:normal;font-variant-east=
-asian:normal;vertical-align:baseline;white-space:pre-wrap"><span style=3D"=
font-size:11pt">SIGHASH_GROUP like constructs would allow uncommitted ephem=
eral anchors to be added at spend time, depending on spending requirements.=
 SIGHASH_SINGLE already allows this.</span></span><br></p></li></ol><div><b=
r></div><div><br></div><div><br></div><p dir=3D"ltr" style=3D"line-height:1=
.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"color:rgb(0,0,0);backg=
round-color:transparent;font-variant-numeric:normal;font-variant-east-asian=
:normal;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-f=
amily:Arial"><span style=3D"font-size:11pt">Hopefully this gives people som=
ething to consider as we move forward in thinking about mempool design with=
in the constraints we have today.</span></span></span><br></p><div><br></di=
v><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma=
rgin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:transpare=
nt;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-alig=
n:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><span st=
yle=3D"font-size:11pt">Greg</span></span></span><br></p><div><br></div><p d=
ir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><spa=
n style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-numer=
ic:normal;font-variant-east-asian:normal;vertical-align:baseline;white-spac=
e:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt=
">0: With V3 transactions where you have &quot;veto power&quot; over all th=
e inputs in that transaction. Therefore something like ANYONECANPAY is stil=
l broken. We need a more complex solution, which I=E2=80=99m punting for th=
e sake of progress.</span></span></span><br></p></span></div><div>_________=
______________________________________<br></div><div>bitcoin-dev mailing li=
st<br></div><div><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br></div><div><a=
 href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" ta=
rget=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev</a><br></div><div><br></div></blockquote><div><br></div></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>
</div></blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>

--0000000000002804ca05eeb1d1b2--