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>
 <CAB3F3DtLzemnNqj6skRcK22qGYVwuo5YCPhUXQDCUcEe3yKr7Q@mail.gmail.com>
 <CAJBJmV_vPW1vBSfTeDOU_FecHk1sX2=uGUFYS9enC=hwvLpVQA@mail.gmail.com>
 <CAB3F3DszC3ZDDYrN_jzoU+hZ021TfmCRoVTZWCpzOmH4F_anwg@mail.gmail.com>
 <CALZpt+FUzpr=3jUfQmqs=LFBjOU=0Ah-snipf-_j1PQKuC4seQ@mail.gmail.com>
In-Reply-To: <CALZpt+FUzpr=3jUfQmqs=LFBjOU=0Ah-snipf-_j1PQKuC4seQ@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Tue, 20 Jun 2023 14:50:47 +0200
Message-ID: <CAJBJmV9K351SG3FTLF0xxC-y5KV4CD6upiQoir+a3p2KBe4fDA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c6195705fe8f1b5a"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Greg Sanders <gsanders87@gmail.com>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

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

Hi Antoine,

On Sun, Jun 18, 2023 at 10:32=E2=80=AFPM Antoine Riard <antoine.riard@gmail=
.com>
wrote:

> > * Opt-in annex (every input must commit to an annex even if its is
> empty) -> make sure existing multi-party protocols remain unaffected
>
> By requiring every input to commit to an annex even if it is empty, do yo=
u
> mean rejecting a transaction where the minimal annex with its 0x50 tag is
> absent ?
>

No what I meant, and what was mentioned by Greg in a previous email, is
that either none of the inputs have an annex, or all of them have one.

So if you're part of a multi-party transaction and you don't commit to an
annex, you can be sure that no version of that tx will appear where another
signer surprises you with a potentially large annex.

For future protocols that rely on the annex, everyone would need to opt-in
by committing to an annex (which can be empty just to signal opt-in).

Joost

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

<div dir=3D"ltr"><div>Hi Antoine,</div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 18, 2023 at 10:32=E2=80=AFPM A=
ntoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@g=
mail.com</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-le=
ft:1ex"><div dir=3D"ltr"><div>&gt; * Opt-in annex (every input must commit =
to an annex even if its is empty) -&gt; make sure existing multi-party prot=
ocols remain unaffected<br></div><br><div>By requiring=C2=A0every input to =
commit to an annex even if it is empty, do you mean rejecting a transaction=
 where the minimal annex with its 0x50 tag is absent ?</div></div></blockqu=
ote><div><br></div><div>No what I meant, and what was mentioned by Greg in =
a previous email, is that either none of the inputs have an annex, or all o=
f them have one.</div><div><br></div><div>So if you&#39;re part of a multi-=
party transaction and you don&#39;t commit to an annex, you can be sure tha=
t no version of that tx will appear where another signer surprises you with=
 a potentially large annex.</div><div><br></div><div>For future protocols t=
hat rely on the annex, everyone would need to opt-in by committing to an an=
nex (which can be empty just to signal opt-in).</div><div><br></div><div>Jo=
ost</div></div></div>

--000000000000c6195705fe8f1b5a--