From: Giacomo Caironi <giacomo.caironi@gmail•com>
To: bitcoin-dev@wuille•net
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Test cases for Taproot signature message
Date: Wed, 6 Oct 2021 22:35:51 +0200 [thread overview]
Message-ID: <CACHAfwfOdhW6HvPs=EgQ-r1maWST_XyT+LM9Z1wh6Th31QUtqg@mail.gmail.com> (raw)
In-Reply-To: <CACHAfwfPTQvUwzqs1mg3Z-FwtcuwGgJfBeK6r0ovtRZKB=rA5A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]
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
>>
>>
[-- Attachment #2: Type: text/html, Size: 5175 bytes --]
next prev parent reply other threads:[~2021-10-06 20:36 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
2021-09-18 11:32 ` Giacomo Caironi
2021-10-06 20:35 ` Giacomo Caironi [this message]
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='CACHAfwfOdhW6HvPs=EgQ-r1maWST_XyT+LM9Z1wh6Th31QUtqg@mail.gmail.com' \
--to=giacomo.caironi@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
/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