From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Giacomo Caironi <giacomo.caironi@gmail•com>
Subject: Re: [bitcoin-dev] Test cases for Taproot signature message
Date: Thu, 16 Sep 2021 22:30:19 +0000 [thread overview]
Message-ID: <NgpYOVuE_3u6zfAZI6cxpc7iB5L_cGtTUrdCJfSdRgChJxOXsY3w0veIk0ZayeEvSeu3SE4AX_E27C6-Yu3MjCFJzMO6AR9g_1CLMJYVG1o=@wuille.net> (raw)
In-Reply-To: <CACHAfwcJrf8kc9+=2+ekjuPTPjW8T6qJS538QQ2DJedAn-XxKA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3675 bytes --]
next prev parent reply other threads:[~2021-09-16 22:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 21:36 Giacomo Caironi
2021-09-16 22:30 ` Pieter Wuille [this message]
2021-09-18 11:32 ` Giacomo Caironi
2021-10-06 20:35 ` Giacomo Caironi
2021-09-17 7:07 ` Riccardo Casatta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='NgpYOVuE_3u6zfAZI6cxpc7iB5L_cGtTUrdCJfSdRgChJxOXsY3w0veIk0ZayeEvSeu3SE4AX_E27C6-Yu3MjCFJzMO6AR9g_1CLMJYVG1o=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=giacomo.caironi@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox