path: root/04/e5a3d142cbfa77587899bedf99349a7d8792da

Return-Path: <giacomo.caironi@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CAECDC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Oct 2021 20:36:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B933B4022F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Oct 2021 20:36:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level: 
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, 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
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 Zx_qfyMq1MOs
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Oct 2021 20:36:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
 [IPv6:2607:f8b0:4864:20::b2d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 34B7940111
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Oct 2021 20:36:03 +0000 (UTC)
Received: by mail-yb1-xb2d.google.com with SMTP id a7so8332898yba.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 06 Oct 2021 13:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=n6D+mvgLl6dyfGnrvOlgXu+R7bdgJjM6WWWkG3Si5yw=;
 b=i0vjiJmhIHroN4Zp0PwT2vn2PNdw30YDrppoBMIiM3kLWzPxT0oSiu9lmHzoKQtNFl
 2iqGxBQWdKgky+h+NjiiLrajJHgXAGbAX4QJWuxsLv2EMilrzZxiHpa2seXWfdSLtC/N
 sZrUrqPFuNvqtbqEcujiSywjLNdlQEelDfk7PD64goKsTJ2k+Vr/C1UkJWGLdkh85T4B
 pcGGF8r1ZYWMDLEnb18Rzibaso9lQ0sJTSzmQtcJSCea0aVVSTxY6I2a92da411UW4by
 HrI0lmJU/xc3Fyq7uAopSTOrLI52CmchW6/5zCuSkNtwjTH4MlMYzDOKkFmunlGbBYfp
 syKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=n6D+mvgLl6dyfGnrvOlgXu+R7bdgJjM6WWWkG3Si5yw=;
 b=7BBwW26ovh1jMo9w/PCALs2/QFphCi643It4x7pAKCIO4pzZOjPdGQwoOfXVbYfKBS
 2UnNO0k8GSIeHKaO0BXCNBGFSrsypN8BrpGr21Nt40gnzt+7dc9uzZ15zsyTINs2F8yG
 SxNefNa8NhauiwUmC0uFKTZMCnQ1FfVaeHSLYCfsvKWRfC7QBiEkUbuGziTJTuDo2FAV
 17GeNnVJhuDlI4xaq9GNPQkirarfIg1jvWwSjVO6+BOe/ULx4wa1ea+0vHV2ZopqGhDX
 4JhGTcbqTW/VmjMx8rPIHVLFBQAf8iq3OhabU91cqr0fndNzaZz3u8DoHtFi6sb1QtAg
 Sn4Q==
X-Gm-Message-State: AOAM532UO6r/qeLp1I5ubxtwpoTRE/fQe5xAMEXbA5l3EOZ+8NiGr1wQ
 D9QUgYj1FG6aMLiA59NQvb02j4IlTUD84APQoSh9aNRRd/kbYQ==
X-Google-Smtp-Source: ABdhPJwAGrBh8ChK5/vmQhBtXkKClvKOKb3oVcTkU7gqyQxVmIPhaprkv/IV3L3uF+VTUKss5dbTAo75pfyMT12401A=
X-Received: by 2002:a5b:145:: with SMTP id c5mr337297ybp.60.1633552562144;
 Wed, 06 Oct 2021 13:36:02 -0700 (PDT)
MIME-Version: 1.0
References: <CACHAfwcJrf8kc9+=2+ekjuPTPjW8T6qJS538QQ2DJedAn-XxKA@mail.gmail.com>
 <NgpYOVuE_3u6zfAZI6cxpc7iB5L_cGtTUrdCJfSdRgChJxOXsY3w0veIk0ZayeEvSeu3SE4AX_E27C6-Yu3MjCFJzMO6AR9g_1CLMJYVG1o=@wuille.net>
 <CACHAfwfPTQvUwzqs1mg3Z-FwtcuwGgJfBeK6r0ovtRZKB=rA5A@mail.gmail.com>
In-Reply-To: <CACHAfwfPTQvUwzqs1mg3Z-FwtcuwGgJfBeK6r0ovtRZKB=rA5A@mail.gmail.com>
From: Giacomo Caironi <giacomo.caironi@gmail.com>
Date: Wed, 6 Oct 2021 22:35:51 +0200
Message-ID: <CACHAfwfOdhW6HvPs=EgQ-r1maWST_XyT+LM9Z1wh6Th31QUtqg@mail.gmail.com>
To: bitcoin-dev@wuille.net
Content-Type: multipart/alternative; boundary="00000000000030483f05cdb5180e"
X-Mailman-Approved-At: Wed, 06 Oct 2021 21:01:11 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Test cases for Taproot signature message
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: Wed, 06 Oct 2021 20:36:04 -0000

--00000000000030483f05cdb5180e
Content-Type: text/plain; charset="UTF-8"

The related pull request is now open
https://github.com/bitcoin/bips/pull/1191

Il giorno sab 18 set 2021 alle ore 13:32 Giacomo Caironi <
giacomo.caironi@gmail.com> ha scritto:

> Ok I have created three test cases, you can find them here
> <https://gist.github.com/giacomocaironi/e41a45195b2ac6863ec46e8f86324757>.
> They cover most of the SigMsg function but they don't cover the ext_flag,
> so they are only for taproot key path; but if you want to test for script
> paths you have to implement more than this function so you would use the
> official test vector.
> Could someone please take a look at them? I think that they are right but
> I am not too sure
>
> Il giorno ven 17 set 2021 alle ore 00:30 Pieter Wuille <
> bitcoin-dev@wuille.net> ha scritto:
>
>> On Thursday, September 16th, 2021 at 5:36 PM, Giacomo Caironi via
>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Hi,
>> recently I have worked on a python implementation of bitcoin signature
>> messages, and I have found that there was way better documentation about
>> Segwit signature message than Taproot.
>>
>> 1) Segwit signature message got its own BIP, completed with test cases
>> regarding only that specific function; Taproot on the other hand has the
>> signature message function defined in BIP 341 and the test vectors in a
>> different BIP (341). This is confusing. Shouldn't we create a different BIP
>> only for Taproot signature message exactly like Segwit?
>>
>>
>> I'm not entirely sure what you mean; you're saying BIP 341 twice.
>>
>> Still, you're right overall - there is no separate BIP for the signature
>> message function. The reason is that the message function is different for
>> BIP341 and BIP342. BIP 341 defines a basic common message function, which
>> is then built up for BIP 341 key path spending, and for BIP 342 tapscript
>> spending. This common part could have been a separate BIP, but that'd still
>> not be a very clean separation. I'm not very inclined to support changing
>> that at this point, given the state of deployment the BIPs have, but that
>> doesn't mean the documentation/vectors can't be improved in the existing
>> documents.
>>
>> 2) The test vectors for Taproot have no documentation and, most
>> importantly, they are not atomic, in the sense that they do not target a
>> specific part of the taproot code but all of it. This may not be a very big
>> problem, but for signature verification it is. Because there are hashes
>> involved, we can't really debug why a signature message doesn't pass
>> validation, either it is valid or it is not. BIP 143 in this case is really
>> good, because it provides hash preimages, so it is possible to debug the
>> function and see where something went wrong. Because of this, writing the
>> Segwit signature hash function took a fraction of the time compared to
>> Taproot.
>>
>>
>> You're right. The existing tests are really intended for verifying an
>> implementation against (and for making sure future code changes don't break
>> anything). They have much higher coverage than the segwit tests had. But
>> they aren't useful as documentation; the code that generates them (
>> https://github.com/bitcoin/bitcoin/blob/v22.0/test/functional/feature_taproot.py#L605L1122)
>> is probably better at that even, but still pretty dense.
>>
>> If this idea is accepted I will be more than happy to write the test
>> cases for Taproot.
>>
>>
>> If you're interested in writing test vectors that are more aimed at
>> helping debugging issues, by all means, do. You've already brought up the
>> sighash code as an example. Another idea, primarily aimed at developers of
>> signing code, is test vectors for certain P2TR scriptPubKeys, derived from
>> certain internal keys and script trees. I'm happy to help to integrate such
>> in Bitcoin Core and the BIP(s).
>>
>> Thanks!
>>
>> Cheers,
>>
>> --
>> Pieter
>>
>>

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

<div dir=3D"ltr">The related pull request is now open=C2=A0<a href=3D"https=
://github.com/bitcoin/bips/pull/1191">https://github.com/bitcoin/bips/pull/=
1191</a></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">Il giorno sab 18 set 2021 alle ore 13:32 Giacomo Caironi &lt;<a hre=
f=3D"mailto:giacomo.caironi@gmail.com">giacomo.caironi@gmail.com</a>&gt; ha=
 scritto:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr">Ok I have created three test cases, you can find them=C2=A0<a hr=
ef=3D"https://gist.github.com/giacomocaironi/e41a45195b2ac6863ec46e8f863247=
57" target=3D"_blank">here</a>. They cover most of the SigMsg function but =
they don&#39;t cover the ext_flag, so they are only for taproot key path; b=
ut if you want to test for script paths you have to implement more than thi=
s function so you would use the official test vector.<div>Could someone ple=
ase take a look at them? I think that they are right but I am not too sure<=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">Il giorno ven 17 set 2021 alle ore 00:30 Pieter Wuille &lt;<a href=3D"=
mailto:bitcoin-dev@wuille.net" target=3D"_blank">bitcoin-dev@wuille.net</a>=
&gt; ha scritto:<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"=
><div>On Thursday, September 16th, 2021 at 5:36 PM, Giacomo Caironi via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div>=
<blockquote type=3D"cite"><div dir=3D"ltr"><div>Hi,=C2=A0<br></div><div>rec=
ently I have worked on a python implementation of bitcoin signature message=
s, and I have found that there was way better documentation about Segwit si=
gnature message than Taproot.<br></div><div><br></div><div>1) Segwit signat=
ure message got its own BIP, completed with test cases regarding only that =
specific function; Taproot on the other hand has the signature message func=
tion defined in BIP 341 and the test vectors in a different BIP (341). This=
 is confusing. Shouldn&#39;t we create a different BIP only for Taproot sig=
nature message exactly like Segwit?<br></div></div></blockquote><div><br></=
div><div>I&#39;m not entirely sure what you mean; you&#39;re saying BIP 341=
 twice.<br></div><div><br></div><div>Still, you&#39;re right overall - ther=
e is no separate BIP for the signature message function. The reason is that=
 the message function is different for BIP341 and BIP342. BIP 341 defines a=
 basic common message function, which is then built up for BIP 341 key path=
 spending, and for BIP 342 tapscript spending. This common part could have =
been a separate BIP, but that&#39;d still not be a very clean separation. I=
&#39;m not very inclined to support changing that at this point, given the =
state of deployment the BIPs have, but that doesn&#39;t mean the documentat=
ion/vectors can&#39;t be improved in the existing documents.<br></div><div>=
<br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div>2) The test vecto=
rs for Taproot have no documentation and, most importantly, they are not at=
omic, in the sense that they do not target a specific part of the taproot c=
ode but all of it. This may not be a very big problem, but for signature ve=
rification it is. Because there are hashes involved, we can&#39;t really de=
bug why a signature message doesn&#39;t pass validation, either it is valid=
 or it is not. BIP 143 in this case is really good, because it provides has=
h preimages, so it is possible to debug the function and see where somethin=
g went wrong. Because of this, writing the Segwit signature hash function t=
ook a fraction of the time compared to Taproot.<br></div></div></blockquote=
><div><br></div><div>You&#39;re right. The existing tests are really intend=
ed for verifying an implementation against (and for making sure future code=
 changes don&#39;t break anything). They have much higher coverage than the=
 segwit tests had. But they aren&#39;t useful as documentation; the code th=
at generates them (<a href=3D"https://github.com/bitcoin/bitcoin/blob/v22.0=
/test/functional/feature_taproot.py#L605L1122" target=3D"_blank">https://gi=
thub.com/bitcoin/bitcoin/blob/v22.0/test/functional/feature_taproot.py#L605=
L1122</a>) is probably better at that even, but still pretty dense.<br></di=
v><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div><div>If th=
is idea is accepted I will be more than happy to write the test cases for T=
aproot.<br></div></div></div></blockquote><div><br></div><div>If you&#39;re=
 interested in writing test vectors that are more aimed at helping debuggin=
g issues, by all means, do. You&#39;ve already brought up the sighash code =
as an example. Another idea, primarily aimed at developers of signing code,=
 is test vectors for certain P2TR scriptPubKeys, derived from certain inter=
nal keys and script trees. I&#39;m happy to help to integrate such in Bitco=
in Core and the BIP(s).<br></div><div><br></div><div>Thanks!<br></div><div>=
<br></div><div>Cheers,<br></div><div><br></div><div>-- <br></div><div>Piete=
r<br></div><div><br></div></blockquote></div>
</blockquote></div>

--00000000000030483f05cdb5180e--