Giacomo Caironi [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-18 📝 Original message:Ok I have created three ...

📅 Original date posted:2021-09-18
📝 Original message: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 at wuille.net> ha scritto:

> On Thursday, September 16th, 2021 at 5:36 PM, Giacomo Caironi via
> bitcoin-dev <bitcoin-dev at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210918/40269758/attachment-0001.html>;