path: root/c1/69829e223f1a8cf78d201299efeba6854268d8

Return-Path: <giacomo.caironi@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1F5ABC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 11:32:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 03F1C4257D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 11:32:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_40=-0.001, 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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 23onYmFUyJKg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 11:32:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com
 [IPv6:2607:f8b0:4864:20::72a])
 by smtp4.osuosl.org (Postfix) with ESMTPS id DD1204257B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 11:32:40 +0000 (UTC)
Received: by mail-qk1-x72a.google.com with SMTP id y144so25957080qkb.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 04:32:40 -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=wKo3Lw0W72+OtJx1xQvGAxkgyxp/H33jhbJedlFK1sw=;
 b=Z31IVwxHCM9MjaCTfK1E8i3f2lPuWsWf+CHTyrQK3Wv/pfwtLxXS31MJO5jatnfbNm
 jdir0R3l+Ogu5wEqZSVG9vsN/6Z3m9lC7m60CHw7Km66yUiL/g3wneqv7+HxjRuW6lhH
 Fogrlvv5PgRgw4ks226ExY7zE/+eX9iyIUUhEiMnDdjOZ9aADMWl7pF7PpVDAdGLuWHv
 6aOSRWdZXHEhZCMaqxHmIrYgXMOCrmMPXZ0uVijlP1mUOZMh5lks3pXwiqkyMaDxT/FD
 4BgTpQzUiKXUOKMxH11CmnZFzM4eU+ZIBRyHNwrE3Zdn50MYP6RlpQhvtqXvaGwkGeUb
 B3fQ==
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=wKo3Lw0W72+OtJx1xQvGAxkgyxp/H33jhbJedlFK1sw=;
 b=Zp6HUnqd1UBxSFQ3kZSn03xaAbz7yVeDRk+trZEBSKXGCQmohql6WXatPp5U3is+3K
 DjcC7+K63V1UHgdM8zJYgGXu84qNSiTjGJKALx/1XbeOZRZ9xbx9RHiTk7Z5jq8rhz95
 rcfwgS8mVaGSm7n/KI/8+gxvor3Fj7JHTff1UX8ypRz8avGUjdw6hSZ1q/bH6gYpY9nK
 8na1c4zjqw2uuhppaGl4W2CGPm9YFF9m4m7rvYhBsaZruqYM72so/8dzoasrO6PcMRny
 KMHHCrH9aJt+9+igt5G3ko5uK2KdkXPAjLDPoS996FhCQZkqCrkMMXR2cJCTVvGw/53I
 X5pQ==
X-Gm-Message-State: AOAM53234ZCkVYniH9ZAzgg65xRXA4SaXTMC3//az/9TljhyVfHl75He
 T/s5U41IWQEZAy+9QlnTRZ3lOi4pJWsFcqJaob4=
X-Google-Smtp-Source: ABdhPJxMf1SdnRXnc5stJEvlrxFvc7juJoReZ0FZq9H7Qp9/iTZectpWZ58LW2wnLHS1E+JjnaCZb8ll5WrXaOm0dfY=
X-Received: by 2002:a25:df45:: with SMTP id w66mr20283325ybg.386.1631964759657; 
 Sat, 18 Sep 2021 04:32:39 -0700 (PDT)
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"
X-Mailman-Approved-At: Sat, 18 Sep 2021 18:04:38 +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: Sat, 18 Sep 2021 11:32:42 -0000

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