path: root/63/929309c1117ec10325c7823fbba5cbe6757cba

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 710BCC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 Jan 2023 02:06:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 4E44D402F5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 Jan 2023 02:06:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4E44D402F5
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=oyDTH3xX
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xi7M3yKmc76r
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 Jan 2023 02:06:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4DD0B4026A
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com
 [IPv6:2607:f8b0:4864:20::d29])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 4DD0B4026A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 Jan 2023 02:06:33 +0000 (UTC)
Received: by mail-io1-xd29.google.com with SMTP id r72so8484349iod.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 Jan 2023 18:06:33 -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=2jF0lIou39IGY9yLt3H2vN8yMvx6/lzY4SCTuzcgsfA=;
 b=oyDTH3xXnKx6qY3JQXhO7ZT23KJ1WiN70UwCBTOsuGod3iE5M2HQMgw3Vlzit1O9Pc
 m5obqlK59gNooc3eWTBoKymasC8bTELkfnoTILK4c0ZTh5PstcZHXxnZR2hLgxPQAsk7
 uWUZ0EenpQA5XMcjgjbMAieJVhLR8rXla6We+et9F3x0hL3wssJAjqovgTdy7Wzd13ag
 Ai7mSU9+U2odaFc8WfNK39ZoxpHmFYdJ2VWvzrjokMcekXyDVFuexmq7qd79gGjzOJPo
 nwfetmYpKx7kQfuoKKaAUsiJq6O0Kq7R0+T75xnWnA8ufx8XWke8jgiO9wbraYp2PulX
 V42A==
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=2jF0lIou39IGY9yLt3H2vN8yMvx6/lzY4SCTuzcgsfA=;
 b=5/KYFic4cfgsS727BeVGXaendBmAg5MwNs+13HLLFWXO0NVtnnYfjncKm8FLyVOeZk
 T5FOeD+/Yk3DthZs0PMeYdskTMVLrPlZJwmYRn3+Z7Tzh2GMsRaf5fpjd3v2xvelMei6
 +aIfYiKSmgwGSrfcDJuv0fjdBPvRqP9YLq/TwOQZznaGPCAhb1WTVCUshabxlbp+EYV7
 DB08kEa1P8RDuC7pXNUXOfUQpnmL6+MUbwew0cDTGDvRosn8Q0blUqayBgCH1/jyfFAm
 +MtiFZg+zjDXG3eB0oh3W9QH8E+I7tEiAkaD8ODHAoq4VjybRQDB480e0GULJsHtqW+H
 cKhw==
X-Gm-Message-State: AFqh2ko0d+QvTYLZTS2kXqg/3vy17p77ebX4NTQpx+h+v6JAnIeIO/Gt
 TefpyC1thWCgeFlgFHsJYNBzIHdB6f2J/4tYgXi1vRhGD2jo3Q==
X-Google-Smtp-Source: AMrXdXuHsKZClPxBvdPbGPa4aTw6eBla0vtWfYfjgZFAxj609bH0VLphqohxaRa+IYexVZFj9CEvF09stac7Wd4CuQw=
X-Received: by 2002:a6b:f801:0:b0:6e3:134:3a97 with SMTP id
 o1-20020a6bf801000000b006e301343a97mr6918818ioh.64.1673489192160; Wed, 11 Jan
 2023 18:06:32 -0800 (PST)
MIME-Version: 1.0
References: <Y75sjuTjsJNT6M7I@erisian.com.au>
In-Reply-To: <Y75sjuTjsJNT6M7I@erisian.com.au>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 11 Jan 2023 21:06:21 -0500
Message-ID: <CALZpt+E4pjhhCkVNs9aoU7DrtzXPnV-RC_yDXTw+q=ehta7kVw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d5936105f207902e"
X-Mailman-Approved-At: Thu, 12 Jan 2023 02:16:27 +0000
Subject: Re: [bitcoin-dev] SIGHASH_GROUP vs Ephemeral anchors
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jan 2023 02:06:35 -0000

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

Hi AJ,

> The idea behind this is that then you can use a signature to link a
> set of inputs and outputs via a signature in a way that's more general
> than SIGHASH_ANYONECANPAY (since you can have many inputs attesting to
> the same subset of outputs), SIGHASH_SINGLE (since you can attest to
> multiple outputs), and SIGHASH_ALL (since you don't have to attest to
> all outputs). This means that (eg) you can have a tx closing a lightning
> channel commit to a dozen outputs that specify where the channel's funds
> end up, but are also able to add additional inputs to cover fees, and
> additional outputs to collect the change from those fees.

To precise more one of the use-case for SIGHASH_GROUP, you can have one LSP
with hundreds of Lightning channels opened with as much (mobile)
counterparties, of which the majority are probably offline most of their
times to aggregate the LN commitment transaction in a single bundle with
one pair of input/output. Aggregation should be non-interactive,
fee-savings from a L2 viewpoint would be all the saved anchor outputs,
blockspace-savings from a full-node viewpoint would be those same anchor
outputs.

> To some degree, this provides an alternative way of getting the same
> benefits of SIGHASH_GROUP: if you were constructing a transaction
> consisting of {i1,i2,i3,i4,f} -> {o1,o2,o3,c} with {i1,i2,i3} committing
to
> {o1} and {i4} committing to {o2,o3} and f providing the fees with c
> collecting the change, you could instead create three transactions:
>
>    {i1,i2,i3} -> {o1, eph1}
>    {i4} -> {o2,o3, eph2}
>    {eph1, eph2, f} -> {c}

I think here a SIGHASH_GROUP-like would be: {i1, i2, i3, i4 i.f, o1, o2,
o3, o.f}. Where `i.f` is the input for feeding external value in the
bundle, `o.f` the output for output fees.

Compared to anchors, I believe you're saving 1-input/2-outputs of fees for
a construction expressing the same semantics ?

> However, it's likely the only benefit to using SIGHASH_ALL there is to
reduce
> malleability risk, and ephemeral anchors probably already achieve that.

If my understanding is correct with ephemeral anchors, we allow third-party
malleability (i.e a entity not owning any key in the funding channel
output) of the chain of transactions. If nversion=3D3 is robust against
"classic" pinnings at the commitment
transaction-level by a counterparty (scenario 2b in [0] iirc), it should
hold against external parties. However, it might introduce issues, where a
common CPFP is conflicted on one of its input, e.g in the example above
eph1 is replaced by  malicious better fee/feerate eph1', cancelling {i4,
o2, o3} fee-bumping.

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.=
html

> The v3.4b rule unfortunately prevents ephemeral anchors from being used
> to provide fees for multiple input/output groups in the way I suggest
> above

See point above, as providing fees for multiple input/output groups *might*
be unsafe, so I think this is a limited downside anyway.

> (I suspect the only way to remove that restriction without reinstating
the pinning
> vector is to allow replacements that have a higher fee rate, even though
> they have a lower absolute fee)

From my memory, I think this is correct -- Though now you're introducing
the issue where one might be able to downgrade the fee content of your
miner mempool in a period of emptiness. However, I believe if we move to a
higher fee rate only, it might make
the cost of the replacement issue above.

> Anyway, in theory, I think ephemeral anchors get most of the potential
> benefits of SIGHASH_GROUP, particularly if the (v3.4b) rule can be remove=
d
> or loosened somehow. And it's obviously much less costly to implement:
> it's relay policy only, rather than a consensus change; and it only
> operates at the transaction level, so we don't have to start worrying
> about pinning of inputs vs whole transactions.

Yes I think the only clear benefit of SIGHASH_GROUP over ephemeral anchors
is the fee/blockspace savings for some types of LN deployments. Comes at
far higher engineering resources as it's a consensus change rather than
relay policy only. However, in the future, if it is combined with other
changes like malleability of the output amounts, it could unlock use-cases
like "dynamic value reallocation" from unknown initial sending.

Best,
Antoine

Le mer. 11 janv. 2023 =C3=A0 03:00, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Hello world,
>
> I think it's interesting to compare SIGHASH_GROUP [0] and Ephemeral
> anchors [1].
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.=
html
> [1] https://github.com/bitcoin/bitcoin/pull/26403
>
> SIGHASH_GROUP is the idea that you provide a way for the inputs of a
> transaction to divide the outputs of a transaction into non-overlapping
> groups. So input 1 can specify "I'm starting a group of 3 outputs",
> input 2 can specify "I'm using the same group as the previous input",
> input 3 can specify "I'm starting a group of 2 outputs"; and each input
> can use the SIGHASH_GROUP flag to specify their signature is signing
> for the subgroup they've specified, rather than just a single output,
> or all of them.
>
> The idea behind this is that then you can use a signature to link a
> set of inputs and outputs via a signature in a way that's more general
> than SIGHASH_ANYONECANPAY (since you can have many inputs attesting to
> the same subset of outputs), SIGHASH_SINGLE (since you can attest to
> multiple outputs), and SIGHASH_ALL (since you don't have to attest to
> all outputs). This means that (eg) you can have a tx closing a lightning
> channel commit to a dozen outputs that specify where the channel's funds
> end up, but are also able to add additional inputs to cover fees, and
> additional outputs to collect the change from those fees.
>
> Ephemeral anchors, by contrast, are just a realy policy level rule that a
> transaction may create a single 0-value output with sPK of OP_TRUE (the
> "ephemeral anchor"), and that that tx won't be rejected as being dust,
> provided that the tx that introduces the anchor pays 0 fees (so it is not
> profitable to mine on its own) and that it's relayed as a package with
> another tx that spends that anchor. (And there are additional proposed
> rules beyond those)
>
> To some degree, this provides an alternative way of getting the same
> benefits of SIGHASH_GROUP: if you were constructing a transaction
> consisting of {i1,i2,i3,i4,f} -> {o1,o2,o3,c} with {i1,i2,i3} committing =
to
> {o1} and {i4} committing to {o2,o3} and f providing the fees with c
> collecting the change, you could instead create three transactions:
>
>    {i1,i2,i3} -> {o1, eph1}
>    {i4} -> {o2,o3, eph2}
>    {eph1, eph2, f} -> {c}
>
> (where eph1/eph2 are ephemeral anchors) and instead of signing with
> SIGHASH_GROUP, you'd just sign with SIGHASH_ALL.
>
> (This is likewise similar to the "sponsored transactions" concept [2],
> where a transaction may "sponsor" another transaction, meaning it cannot
> be included in a block unless the transaction it sponsors is also include=
d
> in the block. Given the "txs-may-only-have-one-sponsor" rule, ephemeral
> anchors could be considered as "you can design a tx that always has a
> sponsor, or never has a sponsor")
>
> [2]
> https://bitcoinops.org/en/newsletters/2020/09/23/#transaction-fee-sponsor=
ship
>
> Ephemeral anchors aren't a complete replacement for SIGHASH_GROUP --
> if i1 had two signatures, one signing with SIGHASH_GROUP, but the other
> signing with SIGHASH_ALL, then it's difficult to duplicate that behaviour
> exactly with ephemeral anchors. However, it's likely the only benefit
> to using SIGHASH_ALL there is to reduce malleability risk, and ephemeral
> anchors probably already achieve that.
>
> Additionally, if the value of i1+i2+i3 was less than o1 or i4 was less
> than o2+o3, then the introduction of f is too late to compensate for
> that with ephemeral anchors, but would have been fine with SIGHASH_GROUP.
>
> The detailed proposed rules for ephemeral anchors as they stand are,
> I think:
>
> > A transaction with one or more CScript([OP_2]) output MUST:
> >  eph.1) Be 0-fee
> >  eph.2) Have [the ephemeral anchor output] spent in the same memppol
> relay
> >         package
> >  eph.3) Be nversion=3D=3D3
> >  eph.4) Must not have more than one [such output]
>
>  -
> https://github.com/bitcoin/bitcoin/pull/26403/commits/431a5e3e0376d8bf555=
63a0168e79dd73b04a1f8
>
> And implied by "nversion=3D=3D3":
>
> > v3.1) A V3 transaction can be replaced, [...]
> > v3.2) Any descendant of an unconfirmed V3 transaction must also be V3.
> > v3.3) A V3 transaction's unconfirmed ancestors must all be V3.
> > v3.4) A V3 transaction cannot have more than 1 descendant.
> > v3.5) A V3 transaction that has an unconfirmed V3 ancestor cannot be
> >    larger than 1000 virtual bytes.
> > v3.4b) A V3 transaction cannot have more than 1 ancestor
>
>  -
> https://github.com/bitcoin/bitcoin/blob/0c089a327a70d16f824b1b4dfd029d260=
cc43f09/doc/policy/version3_transactions.md
>
> The v3.4b rule unfortunately prevents ephemeral anchors from being used
> to provide fees for multiple input/output groups in the way I suggest
> above. That's intended to prevent attaching large ancestors to a package,
> allowing the descendent to be high fee / low feerate, thus preventing
> that descendant from both being replaced (due to requiring a higher
> absolute fee) and mined (due to having a low fee rate). (I suspect the
> only way to remove that restriction without reinstating the pinning
> vector is to allow replacements that have a higher fee rate, even though
> they have a lower absolute fee)
>
> Anyway, in theory, I think ephemeral anchors get most of the potential
> benefits of SIGHASH_GROUP, particularly if the (v3.4b) rule can be remove=
d
> or loosened somehow. And it's obviously much less costly to implement:
> it's relay policy only, rather than a consensus change; and it only
> operates at the transaction level, so we don't have to start worrying
> about pinning of inputs vs whole transactions.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi AJ,<br><br>&gt; The idea behind this is that then you c=
an use a signature to link a<br>&gt; set of inputs and outputs via a signat=
ure in a way that&#39;s more general<br>&gt; than SIGHASH_ANYONECANPAY (sin=
ce you can have many inputs attesting to<br>&gt; the same subset of outputs=
), SIGHASH_SINGLE (since you can attest to<br>&gt; multiple outputs), and S=
IGHASH_ALL (since you don&#39;t have to attest to<br>&gt; all outputs). Thi=
s means that (eg) you can have a tx closing a lightning<br>&gt; channel com=
mit to a dozen outputs that specify where the channel&#39;s funds<br>&gt; e=
nd up, but are also able to add additional inputs to cover fees, and<br>&gt=
; additional outputs to collect the change from those fees.<br><br>To preci=
se more one of the use-case for SIGHASH_GROUP, you can have one LSP with hu=
ndreds of Lightning channels opened with as much (mobile) counterparties, o=
f which the majority are probably offline most of their times to aggregate =
the LN commitment transaction in a single bundle with one pair of input/out=
put. Aggregation should be non-interactive, fee-savings from a L2 viewpoint=
 would be all the saved anchor outputs, blockspace-savings from a full-node=
 viewpoint would be those same anchor outputs.<br><br>&gt; To some degree, =
this provides an alternative way of getting the same<br>&gt; benefits of SI=
GHASH_GROUP: if you were constructing a transaction<br>&gt; consisting of {=
i1,i2,i3,i4,f} -&gt; {o1,o2,o3,c} with {i1,i2,i3} committing to<br>&gt; {o1=
} and {i4} committing to {o2,o3} and f providing the fees with c<br>&gt; co=
llecting the change, you could instead create three transactions:<br>&gt; <=
br>&gt; =C2=A0 =C2=A0{i1,i2,i3} -&gt; {o1, eph1}<br>&gt; =C2=A0 =C2=A0{i4} =
-&gt; {o2,o3, eph2}<br>&gt; =C2=A0 =C2=A0{eph1, eph2, f} -&gt; {c}<br><br>I=
 think here a SIGHASH_GROUP-like would be: {i1, i2, i3, i4 i.f, o1, o2, o3,=
 o.f}. Where `i.f` is the input for feeding external value in the bundle, `=
o.f` the output for output fees.<br><br>Compared to anchors, I believe you&=
#39;re saving 1-input/2-outputs of fees for a construction expressing the s=
ame semantics ?<br><br>&gt; However, it&#39;s likely the only benefit to us=
ing SIGHASH_ALL there is to reduce<br>&gt; malleability risk, and ephemeral=
 anchors probably already achieve that.<br><br>If my understanding is corre=
ct with ephemeral anchors, we allow third-party malleability (i.e a entity =
not owning any key in the funding channel output) of the chain of transacti=
ons. If nversion=3D3 is robust against &quot;classic&quot; pinnings at the =
commitment<br>transaction-level by a counterparty (scenario 2b in [0] iirc)=
, it should hold against external parties. However, it might introduce issu=
es, where a common CPFP is conflicted on one of its input, e.g in the examp=
le above eph1 is replaced by=C2=A0 malicious better fee/feerate eph1&#39;, =
cancelling {i4, o2, o3} fee-bumping.<br><br>[0] <a href=3D"https://lists.li=
nuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html">https://li=
sts.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html</a><b=
r><br>&gt; The v3.4b rule unfortunately prevents ephemeral anchors from bei=
ng used<br>&gt; to provide fees for multiple input/output groups in the way=
 I suggest<br>&gt; above<br><br>See point above, as providing fees for mult=
iple input/output groups *might* be unsafe, so I think this is a limited do=
wnside anyway.<br><br>&gt; (I suspect the only way to remove that restricti=
on without reinstating the pinning<br>&gt; vector is to allow replacements =
that have a higher fee rate, even though<br>&gt; they have a lower absolute=
 fee)<br><br>From my memory, I think this is correct -- Though now you&#39;=
re introducing the issue where one might be able to downgrade the fee conte=
nt of your miner mempool in a period of emptiness. However, I believe if we=
 move to a higher fee rate only, it might make<br>the cost of the replaceme=
nt issue above.<br><br>&gt; Anyway, in theory, I think ephemeral anchors ge=
t most of the potential<br>&gt; benefits of SIGHASH_GROUP, particularly if =
the (v3.4b) rule can be removed<br>&gt; or loosened somehow. And it&#39;s o=
bviously much less costly to implement:<br>&gt; it&#39;s relay policy only,=
 rather than a consensus change; and it only<br>&gt; operates at the transa=
ction level, so we don&#39;t have to start worrying<br>&gt; about pinning o=
f inputs vs whole transactions.<br><br>Yes I think the only clear benefit o=
f SIGHASH_GROUP over ephemeral anchors is the fee/blockspace savings for so=
me types of LN deployments. Comes at far higher engineering resources as it=
&#39;s a consensus change rather than relay policy only. However, in the fu=
ture, if it is combined with other changes like malleability of the output =
amounts, it could unlock use-cases like &quot;dynamic value reallocation&qu=
ot; from unknown initial sending.<br><br>Best,<br>Antoine<br></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 1=
1 janv. 2023 =C3=A0=C2=A003:00, Anthony Towns via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Hello world,<br>
<br>
I think it&#39;s interesting to compare SIGHASH_GROUP [0] and Ephemeral<br>
anchors [1].<br>
<br>
[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021=
-July/019243.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-July/019243.html</a><br>
[1] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26403" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/26403</a><b=
r>
<br>
SIGHASH_GROUP is the idea that you provide a way for the inputs of a<br>
transaction to divide the outputs of a transaction into non-overlapping<br>
groups. So input 1 can specify &quot;I&#39;m starting a group of 3 outputs&=
quot;,<br>
input 2 can specify &quot;I&#39;m using the same group as the previous inpu=
t&quot;,<br>
input 3 can specify &quot;I&#39;m starting a group of 2 outputs&quot;; and =
each input<br>
can use the SIGHASH_GROUP flag to specify their signature is signing<br>
for the subgroup they&#39;ve specified, rather than just a single output,<b=
r>
or all of them.<br>
<br>
The idea behind this is that then you can use a signature to link a<br>
set of inputs and outputs via a signature in a way that&#39;s more general<=
br>
than SIGHASH_ANYONECANPAY (since you can have many inputs attesting to<br>
the same subset of outputs), SIGHASH_SINGLE (since you can attest to<br>
multiple outputs), and SIGHASH_ALL (since you don&#39;t have to attest to<b=
r>
all outputs). This means that (eg) you can have a tx closing a lightning<br=
>
channel commit to a dozen outputs that specify where the channel&#39;s fund=
s<br>
end up, but are also able to add additional inputs to cover fees, and<br>
additional outputs to collect the change from those fees.<br>
<br>
Ephemeral anchors, by contrast, are just a realy policy level rule that a<b=
r>
transaction may create a single 0-value output with sPK of OP_TRUE (the<br>
&quot;ephemeral anchor&quot;), and that that tx won&#39;t be rejected as be=
ing dust,<br>
provided that the tx that introduces the anchor pays 0 fees (so it is not<b=
r>
profitable to mine on its own) and that it&#39;s relayed as a package with<=
br>
another tx that spends that anchor. (And there are additional proposed<br>
rules beyond those)<br>
<br>
To some degree, this provides an alternative way of getting the same<br>
benefits of SIGHASH_GROUP: if you were constructing a transaction<br>
consisting of {i1,i2,i3,i4,f} -&gt; {o1,o2,o3,c} with {i1,i2,i3} committing=
 to<br>
{o1} and {i4} committing to {o2,o3} and f providing the fees with c<br>
collecting the change, you could instead create three transactions:<br>
<br>
=C2=A0 =C2=A0{i1,i2,i3} -&gt; {o1, eph1}<br>
=C2=A0 =C2=A0{i4} -&gt; {o2,o3, eph2}<br>
=C2=A0 =C2=A0{eph1, eph2, f} -&gt; {c}<br>
<br>
(where eph1/eph2 are ephemeral anchors) and instead of signing with<br>
SIGHASH_GROUP, you&#39;d just sign with SIGHASH_ALL.<br>
<br>
(This is likewise similar to the &quot;sponsored transactions&quot; concept=
 [2],<br>
where a transaction may &quot;sponsor&quot; another transaction, meaning it=
 cannot<br>
be included in a block unless the transaction it sponsors is also included<=
br>
in the block. Given the &quot;txs-may-only-have-one-sponsor&quot; rule, eph=
emeral<br>
anchors could be considered as &quot;you can design a tx that always has a<=
br>
sponsor, or never has a sponsor&quot;)<br>
<br>
[2] <a href=3D"https://bitcoinops.org/en/newsletters/2020/09/23/#transactio=
n-fee-sponsorship" rel=3D"noreferrer" target=3D"_blank">https://bitcoinops.=
org/en/newsletters/2020/09/23/#transaction-fee-sponsorship</a><br>
<br>
Ephemeral anchors aren&#39;t a complete replacement for SIGHASH_GROUP --<br=
>
if i1 had two signatures, one signing with SIGHASH_GROUP, but the other<br>
signing with SIGHASH_ALL, then it&#39;s difficult to duplicate that behavio=
ur<br>
exactly with ephemeral anchors. However, it&#39;s likely the only benefit<b=
r>
to using SIGHASH_ALL there is to reduce malleability risk, and ephemeral<br=
>
anchors probably already achieve that.<br>
<br>
Additionally, if the value of i1+i2+i3 was less than o1 or i4 was less<br>
than o2+o3, then the introduction of f is too late to compensate for<br>
that with ephemeral anchors, but would have been fine with SIGHASH_GROUP.<b=
r>
<br>
The detailed proposed rules for ephemeral anchors as they stand are,<br>
I think:<br>
<br>
&gt; A transaction with one or more CScript([OP_2]) output MUST:<br>
&gt;=C2=A0 eph.1) Be 0-fee<br>
&gt;=C2=A0 eph.2) Have [the ephemeral anchor output] spent in the same memp=
pol relay<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0package<br>
&gt;=C2=A0 eph.3) Be nversion=3D=3D3<br>
&gt;=C2=A0 eph.4) Must not have more than one [such output]<br>
<br>
=C2=A0- <a href=3D"https://github.com/bitcoin/bitcoin/pull/26403/commits/43=
1a5e3e0376d8bf55563a0168e79dd73b04a1f8" rel=3D"noreferrer" target=3D"_blank=
">https://github.com/bitcoin/bitcoin/pull/26403/commits/431a5e3e0376d8bf555=
63a0168e79dd73b04a1f8</a><br>
<br>
And implied by &quot;nversion=3D=3D3&quot;:<br>
<br>
&gt; v3.1) A V3 transaction can be replaced, [...]<br>
&gt; v3.2) Any descendant of an unconfirmed V3 transaction must also be V3.=
<br>
&gt; v3.3) A V3 transaction&#39;s unconfirmed ancestors must all be V3.<br>
&gt; v3.4) A V3 transaction cannot have more than 1 descendant.<br>
&gt; v3.5) A V3 transaction that has an unconfirmed V3 ancestor cannot be<b=
r>
&gt;=C2=A0 =C2=A0 larger than 1000 virtual bytes.<br>
&gt; v3.4b) A V3 transaction cannot have more than 1 ancestor<br>
<br>
=C2=A0- <a href=3D"https://github.com/bitcoin/bitcoin/blob/0c089a327a70d16f=
824b1b4dfd029d260cc43f09/doc/policy/version3_transactions.md" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/0c089a327a7=
0d16f824b1b4dfd029d260cc43f09/doc/policy/version3_transactions.md</a><br>
<br>
The v3.4b rule unfortunately prevents ephemeral anchors from being used<br>
to provide fees for multiple input/output groups in the way I suggest<br>
above. That&#39;s intended to prevent attaching large ancestors to a packag=
e,<br>
allowing the descendent to be high fee / low feerate, thus preventing<br>
that descendant from both being replaced (due to requiring a higher<br>
absolute fee) and mined (due to having a low fee rate). (I suspect the<br>
only way to remove that restriction without reinstating the pinning<br>
vector is to allow replacements that have a higher fee rate, even though<br=
>
they have a lower absolute fee)<br>
<br>
Anyway, in theory, I think ephemeral anchors get most of the potential<br>
benefits of SIGHASH_GROUP, particularly if the (v3.4b) rule can be removed<=
br>
or loosened somehow. And it&#39;s obviously much less costly to implement:<=
br>
it&#39;s relay policy only, rather than a consensus change; and it only<br>
operates at the transaction level, so we don&#39;t have to start worrying<b=
r>
about pinning of inputs vs whole transactions.<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<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>

--000000000000d5936105f207902e--