path: root/1c/4fa97b056a3193943f3ca7f901eb902b2c609d

Return-Path: <gsanders87@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AF2B7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 15:51:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 7C6BD40467
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 15:51:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7C6BD40467
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=IEOj6a7/
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id y0MYVHtK10p3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 15:51:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 79392402DC
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [IPv6:2a00:1450:4864:20::52a])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 79392402DC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 15:51:44 +0000 (UTC)
Received: by mail-ed1-x52a.google.com with SMTP id z97so21119206ede.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 08:51:44 -0700 (PDT)
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=2rNoUswizAatCnc6RkyPMp8R3zTaYIGSeYp8hwiZas4=;
 b=IEOj6a7/gib9R5BQGKL8uYMw/Gw4MNGcsNvvr9K5Vs+etA7ROqKrXOAym13Kzq0gn3
 s8cxyQttsCm41KJ1yhswHDGeLeVpVoDJAC2i1jdU54Hp7KwTKTHi/aC36MhOLDO55gqb
 9nPEAD/72gE+8rydliAlZwdEZfId5zg+BC4VDbSaGauwtb/b59E7FDRIbQ4WhyoebhCC
 1FwgLPot/9fdczPQN/QZpyYo494YqzXmnCk5N6m0BjaT87hWhJ8eZSaqtmWCEOlbfwdY
 Z82ZBtv4A0E3egwuyBlqE/REqvyYcGOI2pqg/r7iAj4aHgq6Q3bqOrm4GIfH1CENE2UZ
 dMUw==
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=2rNoUswizAatCnc6RkyPMp8R3zTaYIGSeYp8hwiZas4=;
 b=vyhquKqvomEhhhbDC5GzlQaGPVNNiay7eap3wwdlWH9fPWK5Wzfx1FmuNsaZrLO3fd
 YAWzEVfJC5pGF4YNShIZeVYpgPLjR99UakOa00KlG5OmqbPbe4XsE30gVO+c96jIvE1E
 sebu6hJx2LjC0Ft0WXnJsfgF/xuV/mIGAw9WcPFx8btHUoNggKxuP/gh3cyEPVZ1waHc
 2ZfbPKNRvvUmT4e72o8YanmwLVmBObTQIY44Ag30ePVWQY0r4Qs3jno4O+QtLC27wdt3
 pnK1l3uBma4vLRq4/ZmkO+0Tpet5pxgHsD4DcKIFquoJRHV1Q6cPITJcAPLUtSOdE6Gq
 /96w==
X-Gm-Message-State: ACrzQf1aRgYO57s79oggtEhH2w6OFINwoahWqhrB5D3JbsUMnsScC5tZ
 CDYGJWC1wLEqQ6q4tUbEC2J7uGmz0LnB0MejKAjJm7Hy
X-Google-Smtp-Source: AMsMyM5l+8rPHbRwuX3bPsb0g3VRmDnRp/VyGAy7x0eQnzJm6B1zkoUF8NLWDRkqjG0g/IelveKX2fnEEwAzWvLEEzM=
X-Received: by 2002:a50:ed86:0:b0:458:e1da:af2 with SMTP id
 h6-20020a50ed86000000b00458e1da0af2mr3112503edr.364.1666108302363; Tue, 18
 Oct 2022 08:51:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAB3F3Dukoz3P3Ne7tCxMiwwAGm3Fv8r_fUkNbGAtGhAZDYDgCQ@mail.gmail.com>
 <ec952a9c-d810-4996-9ca9-1e9c6f6faca4@app.fastmail.com>
In-Reply-To: <ec952a9c-d810-4996-9ca9-1e9c6f6faca4@app.fastmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 18 Oct 2022 11:51:30 -0400
Message-ID: <CAB3F3DvH3FnK8krykbcRVKc-z8F4yjt9mzYHevpYxaWkH4w9tw@mail.gmail.com>
To: Arik Sosman <linuxfoundation@arik.io>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000085137005eb51119f"
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: Tue, 18 Oct 2022 15:51:46 -0000

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

> 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 thr=
ee
> 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 implication therefore tha=
t
> 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-September/02=
0937.html
> , I would like to elaborate a bit further on some potential follow-on wor=
k
> 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 be made and
> propagated, it costs the expected amount of fees to do so. This is a grea=
t
> start. What's left in this subset of pinning is *package limit* pinning. =
In
> other words, a fee-paying transaction cannot enter the mempool due to the
> existing mempool package it is being added to already being too large in
> count or vsize.
>
> Zooming into the V3 simplified scenario for sake of discussion, though
> 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 b=
e
> immediately spent by separate parties, this allows one party to 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 o=
n
> it. The honest participant can spend their version with their anchor and
> package RBF the other commitment transaction safely.
>
> What if there's only one version of the commitment transaction, such as i=
n
> other protocols like duplex payment channels, eltoo? What about multi par=
ty
> payments?
>
> In the package RBF proposal, if the parent transaction is identical to an
> existing transaction in the mempool, the parent will be detected and
> removed from the package proposal. You are then left with a single V3 chi=
ld
> transaction, which is then proposed for entry into the mempool. In the ca=
se
> 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 is
> paying "enough" to bump spends from the same parent, it knocks its siblin=
g
> 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 through=
.
>
> 2) Ephemeral Anchors (my real policy-only proposal)
>
> Ephemeral Anchors is a term which means an output is watermarked as an
> output that MUST be spent in a V3 package. We mark this anchor by being t=
he
> bare script `OP_TRUE` and of course make these outputs standard to relay
> 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 we=
ll.
>
> 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 relax this
> policy for maximum smart contract flexibility and specification simplicit=
y..
>
> b) Since this anchor MUST be spent, any spending of other outputs in the
> same parent transaction MUST directly double-spend prior spends of the
> ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
> removed in these situations. This greatly magnifies composability of smar=
t
> contracts, as now we can do things like safely splice directly into new
> channels, into statechains, your custodial wallet account, your cold
> wallet, wherever, without requiring other wallets to support arbitrary
> scripts. Also it hurts that 1 CSV time locked scripts may not be miniscri=
pt
> 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-September/01=
8168.html)
> proposal without consensus changes. As long as someone gets a fully signe=
d
> 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 n=
ot include the output.
>
> d) Lightning Carve-out(
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/00=
2240.html)
> is superseded by this logic, as we are not restricted to two immediately
> spendable output scenarios. In its place, robust multi-party fee bumping =
is
> possible.
>
> e) This also benefits more traditional wallet scenarios, as change output=
s
> can no longer be pinned, and RBF/CPFP becomes robust. Payees in simple
> spends cannot pin you. Batched payouts become a lot less painful. This wa=
s
> 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/015=
717.html),
> even if LN/L2 discussion has largely overtaken it due to HTLC theft risks=
.
>
> 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 directly t=
o
>    fees, and add their own additional fees on top, otherwise miners have
>    incentive to make the smallest utxo burn transaction to claim those fu=
nds.
>    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 requirements.
>    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 i=
n
> that transaction. Therefore something like ANYONECANPAY is still broken. =
We
> need a more complex solution, which I=E2=80=99m punting for the sake of p=
rogress.
> _______________________________________________
> 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
>

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

<div dir=3D"ltr">&gt; does that effectively mark output B as unspendable on=
ce the child gets confirmed?<div><br></div><div>Not at all. It&#39;s a norm=
al spend like before, since the parent has been confirmed. It&#39;s complet=
ely unrestricted, not being bound to any V3/ephemeral anchor restrictions o=
n size, version, etc.</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via=
 bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-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 sharing your=
 proposal!</div><div><br></div><div>I think there&#39;s one thing about the=
 second part of your proposal that I&#39;m missing. Specifically, assuming =
the scenario of a v3 transaction with three outputs, A, B, and the ephemera=
l anchor OP_TRUE. If a child transaction spends A and OP_TRUE, does that ef=
fectively mark output B as unspendable once the child gets confirmed? If so=
, isn&#39;t the implication therefore that to safely spend a transaction wi=
th an ephemeral anchor, all outputs must be spent? Thanks!<br></div><div><b=
r></div><div>Best,<br></div><div>Arik</div><div><br></div><div>On Tue, Oct =
18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:<br></div><blockqu=
ote type=3D"cite" id=3D"m_-7024055043742391057m_4368086065316228638qt"><div=
 dir=3D"ltr"><span id=3D"m_-7024055043742391057m_4368086065316228638qt-gmai=
l-docs-internal-guid-2d3e64aa-7fff-66f1-ed3d-c94d5a1f62c6"><p dir=3D"ltr" s=
tyle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"c=
olor:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;fo=
nt-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">=
<span style=3D"font-family:Arial"><span style=3D"font-size:11pt">Hello Ever=
yone,</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">Following up on the =
&quot;V3 Transaction&quot; discussion here <a href=3D"https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2022-September/020937.html" target=3D"_b=
lank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septembe=
r/020937.html</a> , I would like to elaborate a bit further on some potenti=
al follow-on work that would make pinning severely constrained in many setu=
ps].</span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"lin=
e-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">V3 transactions may s=
olve bip125 rule#3 and rule#5 pinning attacks under some constraints[0]. Th=
is means that when a replacement is to be made and propagated, it costs the=
 expected amount of fees to do so. This is a great start. What&#39;s left i=
n this subset of pinning is *package limit* pinning. In other words, a fee-=
paying transaction cannot enter the mempool due to the existing mempool pac=
kage it is being added to already being too large 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);backgr=
ound-color:transparent;font-variant-numeric:normal;font-variant-east-asian:=
normal;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-fa=
mily:Arial"><span style=3D"font-size:11pt">Zooming into the V3 simplified s=
cenario for sake of discussion, though this problem exists in general today=
:</span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-h=
eight: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-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap"><span style=3D=
"font-family:Arial"><span style=3D"font-size:11pt">V3 transactions restrict=
 the package limit of a V3 package to one parent and one child. If the pare=
nt transaction includes two outputs which can be immediately spent by separ=
ate parties, this allows one party to disallow a spend from the other. In G=
loria&#39;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&#39;s key on it. The honest parti=
cipant can spend their version with their anchor 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;margin-top:0pt;margin-bottom:0pt"><=
span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-nu=
meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-s=
pace:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:1=
1pt">What if there&#39;s only one version of the commitment transaction, su=
ch as in other protocols like duplex payment channels, eltoo? What about mu=
lti party payments?</span></span></span><br></p><div><br></div><p dir=3D"lt=
r" 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:norm=
al;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-w=
rap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">In th=
e package RBF proposal, if the parent transaction is identical to an existi=
ng transaction in the mempool, the parent will be detected and 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 the case of another=
 parent output already being spent, this is simply rejected, regardless of =
feerate of the new child.</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">=
I have two proposed solutions, of which I strongly 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);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">1) Expand a carveout for &quot;=
sibling eviction&quot;, where if the new child is paying &quot;enough&quot;=
 to bump spends from the same parent, it knocks its sibling out of the memp=
ool and takes the one child slot. This would solve it, but is a new evictio=
n paradigm that would need to be carefully worked through.</span></span></s=
pan><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;ver=
tical-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial=
"><span style=3D"font-size:11pt">2) Ephemeral 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-bottom:0pt"><span style=3D"color=
:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-v=
ariant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><spa=
n style=3D"font-family:Arial"><span style=3D"font-size:11pt">Ephemeral Anch=
ors is a term which means an output is watermarked as an output that MUST b=
e spent in a V3 package. We mark this anchor by being the bare script `OP_T=
RUE` and of course make these outputs standard to relay and spend with empt=
y witness data.</span></span></span><br></p><div><br></div><p dir=3D"ltr" s=
tyle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"c=
olor:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;fo=
nt-variant-east-asian:normal;vertical-align:baseline;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 outp=
ut to be 0-fee. This makes mempool reasoning simpler in case the child-spen=
d 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;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">Implications:</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:transpa=
rent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-al=
ign:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><span =
style=3D"font-size:11pt">a) If the ephemeral anchor MUST be spent, we can a=
llow *any* value, even dust, even 0, without worrying about bloating the ut=
xo set. We relax this policy for maximum smart contract flexibility and spe=
cification simplicity..</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">=
b) Since this anchor MUST be spent, any spending of other outputs in the sa=
me parent transaction MUST directly double-spend prior spends of the epheme=
ral anchor. This causes the 1 block CSV timelock on outputs to be removed i=
n these situations. This greatly magnifies composability of smart contracts=
, as now we can do things like safely splice directly into new channels, in=
to statechains, your custodial wallet account, your cold wallet, wherever, =
without requiring other wallets to support arbitrary scripts. Also it hurts=
 that 1 CSV time locked scripts may not be miniscript compatible to begin w=
ith...</span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"l=
ine-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-varian=
t-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><span sty=
le=3D"font-family:Arial"><span style=3D"font-size:11pt">c) *Anyone* can bum=
p the transaction, without any transaction key material. This is essentiall=
y 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 st=
yle=3D"background-color:transparent;font-variant-numeric:normal;font-varian=
t-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;=
white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font=
-size:11pt">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Se=
ptember/018168.html</span></span></span></a><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">) proposal without consen=
sus changes. As long as someone gets a fully signed parent, they can execut=
e 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.</span></s=
pan></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);backgroun=
d-color:transparent;font-variant-numeric:normal;font-variant-east-asian:nor=
mal;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-famil=
y:Arial"><span style=3D"font-size:11pt">d) Lightning Carve-out(</span></spa=
n></span><a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-d=
ev/2019-October/002240.html" style=3D"text-decoration-line:none" target=3D"=
_blank"><span style=3D"background-color:transparent;font-variant-numeric:no=
rmal;font-variant-east-asian:normal;text-decoration-line:underline;vertical=
-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><sp=
an style=3D"font-size:11pt">https://lists.linuxfoundation.org/pipermail/lig=
htning-dev/2019-October/002240.html</span></span></span></a><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">)=C2=A0 i=
s superseded by this logic, as we are not restricted to two immediately spe=
ndable output scenarios. In its place, robust multi-party fee bumping is po=
ssible.</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-varia=
nt-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><span st=
yle=3D"font-family:Arial"><span style=3D"font-size:11pt">e) This also benef=
its more traditional wallet scenarios, as change outputs can no longer be p=
inned, and RBF/CPFP becomes robust. Payees in simple 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 plac=
e(</span></span></span><a href=3D"https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2018-February/015717.html" style=3D"text-decoration-line:non=
e" target=3D"_blank"><span style=3D"background-color:transparent;font-varia=
nt-numeric:normal;font-variant-east-asian:normal;text-decoration-line:under=
line;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-fami=
ly:Arial"><span style=3D"font-size:11pt">https://lists.linuxfoundation.org/=
pipermail/bitcoin-dev/2018-February/015717.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">), even if LN/L2 discussion has largely overtaken it due to HTLC theft r=
isks.</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">Open Question(s):</s=
pan></span></span><br></p><div><br></div><ol style=3D"margin-top:0px;margin=
-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:decimal;font-size:11p=
t;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-vari=
ant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;w=
hite-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0p=
t;margin-bottom:0pt" role=3D"presentation"><span style=3D"background-color:=
transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vert=
ical-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 a=
re worried about? Wallets should toss all the value directly to fees, and a=
dd their own additional fees on top, otherwise miners have incentive to mak=
e the smallest utxo burn transaction to claim those funds. They just confir=
med your parent transaction anyways, so do we care?</span></span><br></p></=
li><li dir=3D"ltr" style=3D"list-style-type:decimal;font-size:11pt;font-fam=
ily:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeri=
c:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space=
:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-b=
ottom:0pt" role=3D"presentation"><span style=3D"background-color:transparen=
t;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align=
:baseline;white-space:pre-wrap"><span style=3D"font-size:11pt">SIGHASH_GROU=
P like constructs would allow uncommitted ephemeral anchors to be added at =
spend time, depending on spending requirements. SIGHASH_SINGLE already allo=
ws this.</span></span><br></p></li></ol><div><br></div><div><br></div><div>=
<br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bo=
ttom:0pt"><span style=3D"color:rgb(0,0,0);background-color:transparent;font=
-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:basel=
ine;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"=
font-size:11pt">Hopefully this gives people something to consider as we mov=
e forward in thinking about mempool design within the constraints we have t=
oday.</span></span></span><br></p><div><br></div><div><br></div><p dir=3D"l=
tr" 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:norm=
al;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-w=
rap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">Greg<=
/span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-hei=
ght: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"f=
ont-family:Arial"><span style=3D"font-size:11pt">0: With V3 transactions wh=
ere you have &quot;veto power&quot; over all the inputs in that transaction=
. Therefore something like ANYONECANPAY is still broken. We need a more com=
plex solution, which I=E2=80=99m punting for the sake of progress.</span></=
span></span><br></p></span></div><div>_____________________________________=
__________<br></div><div>bitcoin-dev mailing list<br></div><div><a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a><br></div><div><a href=3D"https://lists.linux=
foundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://list=
s.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>

--00000000000085137005eb51119f--