MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
 <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
 <CAJBJmV88j7i3=uqnU5OwMCKyZaP9v6cx9EKEuK1FYs6aL0r1uw@mail.gmail.com>
In-Reply-To: <CAJBJmV88j7i3=uqnU5OwMCKyZaP9v6cx9EKEuK1FYs6aL0r1uw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 15 Jun 2023 06:39:36 -0400
Message-ID: <CAB3F3DtLzemnNqj6skRcK22qGYVwuo5YCPhUXQDCUcEe3yKr7Q@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f4bf0305fe28afa6"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

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

Hi Joost,

> Ignoring the argument that policy may provide a false sense of security

This may take longer form arguments than I'm willing to make on this
thread, but I think this only true in a shallower sense that we cannot know
for sure that anything will be confirmed quickly. When crafting policy, we
are trying to make as reliable-as-possible systems to allow people to pay
miners. That may mean opening up the annex to potential use-cases, but it
certainly means allowing current users of the p2p network to make
reasonable feerate transactions in coinjoin-like scenarios. Ideally we
shoot for as many use cases as we can, to pay these miners.

> Would it then still be necessary to restrict the annex to a maximum size?

I think it's worth thinking about to protect the opt-in users, and can also
be used for other anti-pinning efforts(though clearly not sufficient by
itself for the many many pinning vectors we have :) )

Cheers,
Greg

On Thu, Jun 15, 2023 at 5:36=E2=80=AFAM Joost Jager <joost.jager@gmail.com>=
 wrote:

> Hi Greg,
>
> Getting back to this:
>
> 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.
>>
>
> Ignoring the argument that policy may provide a false sense of security, =
I
> think this is an interesting idea. Opt-in would enable convenants through
> presigned txes with atomic on-chain signature backup, without needing to
> worry about non-annex multi-party protocols (coinjoin and dual funded
> lightning mentioned previously) that may suffer from annex inflation or t=
he
> last signer presenting an unexpected annex. The downside is just that ext=
ra
> empty annex byte per input, if there are other inputs involved. To me tha=
t
> would be a reasonable trade-off.
>
> Would it then still be necessary to restrict the annex to a maximum size?
> Perhaps not opting into annex for multi-party protocols is sufficient. Or
> otherwise, #24007 may be helpful. It is hard to pick a constant usually.
>
> Joost.
>

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

<div dir=3D"ltr">Hi Joost,<div><br></div><div>&gt; Ignoring the argument th=
at policy may provide a false sense of security</div><div><br></div><div>Th=
is may take longer form arguments than I&#39;m willing to make on this thre=
ad, but I think this only true in a shallower sense that we cannot know for=
 sure that anything will be confirmed quickly. When crafting policy, we are=
 trying to make as reliable-as-possible systems to allow people to pay mine=
rs. That may mean opening up the annex to potential use-cases, but it certa=
inly means allowing current users of the p2p network to make reasonable fee=
rate transactions=C2=A0in coinjoin-like scenarios. Ideally we shoot for as =
many use cases as we can, to pay these miners.</div><div><br></div><div>&gt=
; Would it then still be necessary to restrict the annex to a maximum size?=
</div><div><br></div><div>I think it&#39;s worth thinking about to protect =
the opt-in users, and can also be used for other anti-pinning efforts(thoug=
h clearly not sufficient by itself for the many many pinning vectors we hav=
e :) )</div><div><br></div><div>Cheers,</div><div>Greg</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 15,=
 2023 at 5:36=E2=80=AFAM Joost Jager &lt;<a href=3D"mailto:joost.jager@gmai=
l.com">joost.jager@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_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>Hi Greg,</div><div><br></=
div><div>Getting back to this:</div><div><br></div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
id=3D"m_-6262746064179201819m_-3252546504006912555gmail-:3hl" aria-label=3D=
"Message Body" role=3D"textbox" aria-multiline=3D"true" style=3D"direction:=
ltr;min-height:85px" aria-controls=3D":3k2"><div>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 relay-standard. In this case, you&#39;ve opted in=
to a possible</div><div>vector, but at least current usage patterns wouldn&=
#39;t be unduly affected.=C2=A0</div></div></div></blockquote><div>=C2=A0</=
div><div>Ignoring the argument that policy may provide a false sense of sec=
urity, I think this is an interesting idea. Opt-in would enable convenants =
through presigned txes with atomic on-chain signature backup, without needi=
ng to worry about non-annex multi-party protocols (coinjoin and dual funded=
 lightning mentioned previously) that may suffer from annex inflation or th=
e last signer presenting an unexpected annex. The downside is just that ext=
ra empty annex byte per input, if there are other inputs involved. To me th=
at would be a reasonable trade-off.</div><div><br></div><div>Would it then =
still be necessary to restrict the annex to a maximum size? Perhaps not opt=
ing into annex for multi-party protocols is sufficient. Or otherwise, #2400=
7 may be helpful. It is hard to pick a constant usually.</div><div><br></di=
v><div>Joost.</div></div></div>
</blockquote></div>

--000000000000f4bf0305fe28afa6--