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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Test cases for Taproot signature message
Precedence: list

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