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