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
Precedence: list

--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--