MIME-Version: 1.0
References: <CACHAfwcJrf8kc9+=2+ekjuPTPjW8T6qJS538QQ2DJedAn-XxKA@mail.gmail.com>
 <NgpYOVuE_3u6zfAZI6cxpc7iB5L_cGtTUrdCJfSdRgChJxOXsY3w0veIk0ZayeEvSeu3SE4AX_E27C6-Yu3MjCFJzMO6AR9g_1CLMJYVG1o=@wuille.net>
In-Reply-To: <NgpYOVuE_3u6zfAZI6cxpc7iB5L_cGtTUrdCJfSdRgChJxOXsY3w0veIk0ZayeEvSeu3SE4AX_E27C6-Yu3MjCFJzMO6AR9g_1CLMJYVG1o=@wuille.net>
From: Giacomo Caironi <giacomo.caironi@gmail.com>
Date: Sat, 18 Sep 2021 13:32:28 +0200
Message-ID: <CACHAfwfPTQvUwzqs1mg3Z-FwtcuwGgJfBeK6r0ovtRZKB=rA5A@mail.gmail.com>
To: bitcoin-dev@wuille.net
Content-Type: multipart/alternative; boundary="000000000000c9103305cc4367e9"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Test cases for Taproot signature message
Precedence: list

--000000000000c9103305cc4367e9
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr">Ok I have created three test cases, you can find them=C2=
=A0<a href=3D"https://gist.github.com/giacomocaironi/e41a45195b2ac6863ec46e=
8f86324757" target=3D"_blank">here</a>. They cover most of the SigMsg funct=
ion but they don&#39;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.<div>Could som=
eone please take a look at them? I think that they are right but I am not t=
oo sure</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">Il giorno ven 17 set 2021 alle ore 00:30 Pieter Wuille &lt;<a =
href=3D"mailto:bitcoin-dev@wuille.net">bitcoin-dev@wuille.net</a>&gt; ha sc=
ritto:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On T=
hursday, September 16th, 2021 at 5:36 PM, Giacomo Caironi via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e type=3D"cite"><div dir=3D"ltr"><div>Hi,=C2=A0<br></div><div>recently I ha=
ve worked on a python implementation of bitcoin signature messages, and I h=
ave found that there was way better documentation about Segwit signature me=
ssage than Taproot.<br></div><div><br></div><div>1) Segwit signature messag=
e got its own BIP, completed with test cases regarding only that specific f=
unction; Taproot on the other hand has the signature message function defin=
ed in BIP 341 and the test vectors in a different BIP (341). This is confus=
ing. Shouldn&#39;t we create a different BIP only for Taproot signature mes=
sage 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 - there is no se=
parate BIP for the signature message function. The reason is that the messa=
ge function is different for BIP341 and BIP342. BIP 341 defines a basic com=
mon 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 sep=
arate 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 d=
eployment the BIPs have, but that doesn&#39;t mean the documentation/vector=
s 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 vectors for Tap=
root have no documentation and, most importantly, they are not atomic, in t=
he sense that they do not target a specific part of the taproot code but al=
l of it. This may not be a very big problem, but for signature verification=
 it is. Because there are hashes involved, we can&#39;t really debug 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 hash preimage=
s, so it is possible to debug the function and see where something went wro=
ng. Because of this, writing the Segwit signature hash function took a frac=
tion of the time compared to Taproot.<br></div></div></blockquote><div><br>=
</div><div>You&#39;re right. The existing tests are really intended for ver=
ifying an implementation against (and for making sure future code changes d=
on&#39;t break anything). They have much higher coverage than the segwit te=
sts had. But they aren&#39;t useful as documentation; the code that generat=
es them (<a href=3D"https://github.com/bitcoin/bitcoin/blob/v22.0/test/func=
tional/feature_taproot.py#L605L1122" target=3D"_blank">https://github.com/b=
itcoin/bitcoin/blob/v22.0/test/functional/feature_taproot.py#L605L1122</a>)=
 is probably better at that even, but still pretty dense.<br></div><div><br=
></div><blockquote type=3D"cite"><div dir=3D"ltr"><div><div>If this idea is=
 accepted I will be more than happy to write the test cases for Taproot.<br=
></div></div></div></blockquote><div><br></div><div>If you&#39;re intereste=
d in writing test vectors that are more aimed at helping debugging issues, =
by all means, do. You&#39;ve already brought up the sighash code as an exam=
ple. Another idea, primarily aimed at developers of signing code, is test v=
ectors for certain P2TR scriptPubKeys, derived from certain internal keys a=
nd script trees. I&#39;m happy to help to integrate such in Bitcoin Core an=
d 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>Pieter<br></div=
><div><br></div></blockquote></div>

--000000000000c9103305cc4367e9--