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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
