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

--0000000000002a902e05fe27cfef
Content-Type: text/plain; charset="UTF-8"

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 the
last signer presenting an unexpected annex. The downside is just that extra
empty annex byte per input, if there are other inputs involved. To me that
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.

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

<div dir=3D"ltr"><div>Hi Greg,</div><div><br></div><div>Getting back to thi=
s:</div><div><br></div><div class=3D"gmail_quote"><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"><div dir=3D"ltr"><div id=3D"m_-3252546504006912555=
gmail-: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>A=
nother solution could be to make annex usage &quot;opt-in&quot;</div><div>b=
y requiring all inputs to commit to an annex to be relay-standard. In this =
case, you&#39;ve opted into a possible</div><div>vector, but at least curre=
nt 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 pro=
vide a false sense of security, I think this is an interesting idea. Opt-in=
 would enable convenants through presigned txes with atomic on-chain signat=
ure backup, without needing to worry about non-annex multi-party protocols =
(coinjoin and dual funded lightning mentioned previously) that may suffer f=
rom annex inflation or the last signer presenting an unexpected annex. The =
downside is just that extra empty annex byte per input, if there are other =
inputs involved. To me that would be a reasonable trade-off.</div><div><br>=
</div><div>Would it then still be necessary to restrict the annex to a maxi=
mum size? Perhaps not opting into annex for multi-party protocols is suffic=
ient. Or otherwise, #24007 may be helpful. It is hard to pick a constant us=
ually.</div><div><br></div><div>Joost.</div></div></div>

--0000000000002a902e05fe27cfef--