path: root/1f/0dc0b1a80986e36b3b213cbb7125fd48097b27

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 77CBAC0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 01:14:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 420A1428DF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 01:14:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 420A1428DF
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=MDOtHuSn
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ZpH2S_D7IOtZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 01:14:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6E9F94282A
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [IPv6:2a00:1450:4864:20::62d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 6E9F94282A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jun 2023 01:14:53 +0000 (UTC)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-9745c5fed21so244245066b.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 02 Jun 2023 18:14:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1685754891; x=1688346891;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=GLZ29vLlLHoPTBBR1QhYrFqRzkGgkPBsya1c47yMxwU=;
 b=MDOtHuSndt0JDmJSh5rdWzGcqg3Yq+gPxC2lNUMEMhR3KphL4YPnQmaoMUZmRBQ8dl
 LoqMuyZb1CMXk/H6fEJIPlOEoh7Z/MrXLQKs/pPNKHQOqfju10nSU14dOIYNeO3FOjWl
 4N7hC6nPQDoXpsC02Ogbf4Xjhhe9xrHr7fzyqwKfN6RxqjrKOIzBi8RZU9NyYSEzW0/d
 jRj6EYkNJy4Vya1pNiOXVY0qK/ZCxOpx/Rq2y9FxzijeHdI03Rom9kWdQQVoir8k2A17
 TwzMPt2Awuv4ddB4Y126DM/UYXLd3LY0es7WaAdUsroPmigE6uekcRn68nZNsz1NVmDQ
 OFxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1685754891; x=1688346891;
 h=cc: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=GLZ29vLlLHoPTBBR1QhYrFqRzkGgkPBsya1c47yMxwU=;
 b=SgBCh5fEwbVrZUNdddjYp5s7LUhQ/Q8t55UkscBIXd1RAUi037ETF9BX/HU1oS0gTQ
 3dD/X9YQ5ITDA7PE4SKw071Zkn8G0tJunBJyy8DVNxRq29RVtzfYEmpUo0w2tT0mD80+
 aBpRiUnN6m4LjtMe/p9DFZDM5wMi0i40sm/DN2q89XjEUxTaa/MFpHX82qesTatYtb9j
 46HGpknlbAbHXisS39+qyF5VCrnzg9zi9cGvnvq9u2tyjh1DCQPu6SOjOICigOMhEHR9
 KDzcw/0XRZjfzXAu1wOJaEyEIYgHb2CkpXxTboxheLeRIplapYS3/8ZtioNxJChPVDsM
 eoSw==
X-Gm-Message-State: AC+VfDz1DLlkvKXO3m68gDZxjObvyXBPNjSXNVFHjptr2+HkA0jcakyc
 wbyDQx1OxyJGEuJQDF6mOszviz3gLyI9m89SrTVqB/GOtbg=
X-Google-Smtp-Source: ACHHUZ7qDIxh4aWVYJv26ydakqDIImElBg9ZsCN9lkr7XYztba46r0BrXHtHbGLLljIrjbOhxqvwwX5lNkfnsDBkZ/g=
X-Received: by 2002:a17:906:da84:b0:973:940e:a01b with SMTP id
 xh4-20020a170906da8400b00973940ea01bmr269628ejb.60.1685754891143; Fri, 02 Jun
 2023 18:14:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
In-Reply-To: <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 2 Jun 2023 21:14:40 -0400
Message-ID: <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007711df05fd2f659c"
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jun 2023 01:14:55 -0000

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

Hello Joost, David,

Thanks for the link to my ln-symmetry draft David. I'd also be curious as
to the usage you have in
mind Joost.

It's probably helpful to cite the most recent discussions on the topic,
which is probably
https://github.com/bitcoin-inquisition/bitcoin/pull/22 , where
bitcoin-inquisition has included
the `annexcarrier` option. I have a particular use for APO-enabled payment
channel designs
that doesn't require consensus meaning, so some effort was put in to try
something out there.

Attempting to summarize the linked PR:

I think the biggest remaining issue to this kind of idea, which is why I
didn't propose it for mainnet,
is the fact that BIP341/342 signature hashes do not cover *other* inputs'
annex fields, which we
briefly discussed here
https://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r11433822=
64
.

This means that in a coinjoin like scenario, even if the other joining
parties prove they don't have any
crazy script paths, a malicious party can make the signed transaction into
a maximum sized transaction
package, causing griefing. The mitigation in the PR I linked was to limit
it to 126 bytes, basically punting
on the problem by making the grief vector small. Another solution could be
to make annex usage "opt-in"
by requiring all inputs to commit to an annex to be relay-standard. In this
case, you've opted into a possible
vector, but at least current usage patterns wouldn't be unduly affected.
For those who opt-in, perhaps the first
order of business would be to have a field that limits the total
transaction weight, by policy only?

Some logs related to that here:
https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb

Related discussion on possible BIP118 modifications to mitigate this in
tapscript-spending circumstances:
https://github.com/bitcoin-inquisition/bitcoin/issues/19

Anyways, curious to hear what people think and want to make sure everyone
is on the same page.

Best,
Greg

On Fri, Jun 2, 2023 at 9:08=E2=80=AFPM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:
> > the benefits of making the annex available in a
> > non-structured form are both evident and immediate. By allowing
> > developers to utilize the taproot annex without delay, we can take
> > advantage of its features today,
>
> Hi Joost,
>
> Out of curiosity, what features and benefits are available today?  I
> know Greg Sanders wants to use annex data with LN-Symmetry[1], but
> that's dependent on a soft fork of SIGHASH_ANYPREVOUT.  I also heard you
> mention that it could allow putting arbitrary data into a witness
> without having to commit to that data beforehand, but that would only
> increase the efficiency of witness stuffing like ordinal inscriptions by
> only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
> required to create an output in order to spend it.
>
> Is there some other way to use the annex today that would be beneficial
> to users of Bitcoin?
>
> -Dave
>
> [1]
>
> https://github.com/lightning/bolts/compare/master...instagibbs:bolts:elto=
o_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800a=
e2R119
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div id=3D"gmail-:3hl" class=3D"gmail-Am gmail-aO9 gmail-A=
l editable gmail-LW-avf gmail-tS-tW gmail-tS-tY" aria-label=3D"Message Body=
" role=3D"textbox" aria-multiline=3D"true" tabindex=3D"1" style=3D"directio=
n:ltr;min-height:85px" aria-controls=3D":3k2">Hello Joost, David,<div><br><=
/div><div>Thanks for the link to my ln-symmetry draft David. I&#39;d also b=
e curious as to the usage you have in</div><div>mind Joost.</div><div><br><=
/div><div>It&#39;s probably helpful to cite the most recent discussions on =
the topic, which is probably</div><div><a href=3D"https://github.com/bitcoi=
n-inquisition/bitcoin/pull/22">https://github.com/bitcoin-inquisition/bitco=
in/pull/22</a> , where bitcoin-inquisition has included<br></div><div>the `=
annexcarrier` option. I have a particular use for APO-enabled payment chann=
el designs</div><div>that doesn&#39;t require consensus meaning, so some ef=
fort was put in to try something out there.</div><div><br></div><div>Attemp=
ting to summarize the linked PR:</div><div><br></div><div>I think the bigge=
st remaining issue to this kind of idea, which is why I didn&#39;t propose =
it for mainnet,</div><div>is the fact that BIP341/342 signature hashes do n=
ot cover *other* inputs&#39; annex fields, which we</div><div>briefly discu=
ssed here=C2=A0<a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pu=
ll/22#discussion_r1143382264">https://github.com/bitcoin-inquisition/bitcoi=
n/pull/22#discussion_r1143382264</a> .=C2=A0</div><div><br></div><div>This =
means that in a coinjoin like scenario, even if the other joining parties p=
rove they don&#39;t have any</div><div>crazy script paths, a malicious part=
y can make the signed transaction into a maximum sized transaction</div><di=
v>package, causing griefing. The mitigation in the PR I linked was to limit=
 it to 126 bytes, basically punting</div><div>on the problem by making the =
grief vector small. Another solution could be to make annex usage &quot;opt=
-in&quot;</div><div>by requiring all inputs to commit to an annex to be rel=
ay-standard. In this case, you&#39;ve opted into a possible</div><div>vecto=
r, but at least current usage patterns wouldn&#39;t be unduly affected. For=
 those who opt-in, perhaps the first</div><div>order of business would be t=
o have a field that limits the total transaction weight, by policy only?</d=
iv><div><br></div><div>Some logs related to that here:=C2=A0<a href=3D"http=
s://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb">https://gi=
st.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb</a></div><div><br=
></div><div>Related discussion on possible BIP118 modifications to mitigate=
 this in tapscript-spending circumstances:=C2=A0<a href=3D"https://github.c=
om/bitcoin-inquisition/bitcoin/issues/19">https://github.com/bitcoin-inquis=
ition/bitcoin/issues/19</a></div><div><br></div><div>Anyways, curious to he=
ar what people think and want to make sure everyone is on the same page.</d=
iv><div><br></div><div>Best,</div><div>Greg</div></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 2, 2023 =
at 9:08=E2=80=AFPM David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:<br>
&gt; the benefits of making the annex available in a<br>
&gt; non-structured form are both evident and immediate. By allowing<br>
&gt; developers to utilize the taproot annex without delay, we can take<br>
&gt; advantage of its features today,<br>
<br>
Hi Joost,<br>
<br>
Out of curiosity, what features and benefits are available today?=C2=A0 I <=
br>
know Greg Sanders wants to use annex data with LN-Symmetry[1], but <br>
that&#39;s dependent on a soft fork of SIGHASH_ANYPREVOUT.=C2=A0 I also hea=
rd you <br>
mention that it could allow putting arbitrary data into a witness <br>
without having to commit to that data beforehand, but that would only <br>
increase the efficiency of witness stuffing like ordinal inscriptions by <b=
r>
only 0.4% (~2 bytes saved per 520 bytes pushed) and it&#39;d still be <br>
required to create an output in order to spend it.<br>
<br>
Is there some other way to use the annex today that would be beneficial <br=
>
to users of Bitcoin?<br>
<br>
-Dave<br>
<br>
[1] <br>
<a href=3D"https://github.com/lightning/bolts/compare/master...instagibbs:b=
olts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45f=
e5bd8800ae2R119" rel=3D"noreferrer" target=3D"_blank">https://github.com/li=
ghtning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274=
046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119</a><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>

--0000000000007711df05fd2f659c--