path: root/ac/6fac22094abe59ac50ce1ebf1d1922298cef06

Return-Path: <joost.jager@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2F2DEC0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 12:51:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 1114C40412
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 12:51:26 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1114C40412
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=al1z0v3x
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MTCk3Dosltxc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 12:51:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3BE7C40102
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [IPv6:2a00:1450:4864:20::52f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3BE7C40102
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 12:51:25 +0000 (UTC)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-51a20138617so6484695a12.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 20 Jun 2023 05:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1687265483; x=1689857483;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=9Z9d2JOWggGAkjaBD/OyLtjvhVziLY10lX+S5v+Olag=;
 b=al1z0v3xdQNUjoOHCLtpevGXcbRZCX0de1SaVjrZ4FgLLkhsg5VT4rd1t1FMKyNbCV
 mnYJs6jhpnO2qOWOZ7Gx1CPBnoVGFaVAJCjG5ei1v5XmF2HFtvh5JRyCQguZ/TeEJUVH
 E/dAyctXO5R8klCF09uqfRULlzSu2Hp8ckaPwmNKWu3jdrCzDssO8WJMM7w+QorxiQ4c
 9XF/9b8pCoWQPPC3jJmROgr9p2/IL/PmiV2CmJd1XUo/CGrPxFSVaOpvhgXt2BA2Hi6w
 UEaHiLrIiJtlhHI9TF//0+fBrGwEreogJpuLNCDAWN/6QfIIHxEMDEvBbeif+UpWAig5
 vwTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1687265483; x=1689857483;
 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=9Z9d2JOWggGAkjaBD/OyLtjvhVziLY10lX+S5v+Olag=;
 b=G/5LdwIoIgxtunfBjwn/FF/3BClJvewy6PmaT+XhyBQRscp6RuI0mOvKA2nzqz+A7Y
 J6XbLspC3Idi+bn+1B80wrQFWiQyzYi9ZcsOWuwMyXPPn9BTJcJigXix5hPwrYDLtTtW
 e9P+tsoffjVhej3sU+qBaIr+p7PmZZG43s/flVB3OsC1DTacYfGUVulhKFNIC7XmA5qa
 +oIdLPXJtgdiL+5JIy6fXLdAZ+i+CXl2iQABmSX9S5uYlofwRATpmRq6A8RweNM6qIKS
 Qvxqr7P1ZdWbQWql8NlKWJIOHAYkSAavKMag1v2H9y4LeaW94yYvtGpODUl0Hj12Mu7M
 8OOA==
X-Gm-Message-State: AC+VfDxPNXmdPqKBA7vekXhmOJhaFaVa58Zwa32bb80TYbq09Y7jtzAa
 f3ZlKp7z/1bhZuOypmX/Rf+LX9u3k/YZHKp3tM4=
X-Google-Smtp-Source: ACHHUZ5JxmvEZfpuUZ9afj+Z+9kNX0zaUVH4BpbffohzAdxK/NL67UX1D9TRpkBw4LqslGiFZOWpdAuvvaluHvgSih4=
X-Received: by 2002:a17:907:9627:b0:988:3943:aaa4 with SMTP id
 gb39-20020a170907962700b009883943aaa4mr8546733ejc.29.1687265483297; Tue, 20
 Jun 2023 05:51:23 -0700 (PDT)
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"
X-Mailman-Approved-At: Tue, 20 Jun 2023 12:59:53 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Greg Sanders <gsanders87@gmail.com>
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: Tue, 20 Jun 2023 12:51:26 -0000

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