From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B4A30C000D for ; Thu, 16 Sep 2021 21:37:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9D853607FE for ; Thu, 16 Sep 2021 21:37:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puKrfHI4ZSKY for ; Thu, 16 Sep 2021 21:37:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by smtp3.osuosl.org (Postfix) with ESMTPS id DAB8B60730 for ; Thu, 16 Sep 2021 21:37:00 +0000 (UTC) Received: by mail-qk1-x735.google.com with SMTP id ay33so10933845qkb.10 for ; Thu, 16 Sep 2021 14:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=rmm7Ntd1/M38rKLdi8KrFPB93RRenrDKyHORXPxSVKQ=; b=qqNYXIrArc3s4BS9nB2Qa7dVvLq7TDOBvQWh4jYGBNBttp6z0YFrGQJs0EmBqVpmNb mhXAmWGvEJy1GeOfkDiWZNM92lSJJ76JpPxXPfryCax+YZ2e3yx23H3tqJMhQLJy0AWL 8A2n+ZIdd3/ijoN1ip8EPVwX027ckAmjP9vqwm8qq9kc/ESD6HbVK/iCzsZxWbhkr0W6 A/KCCMR5paOXtG+RdhQpdLJF+rfCbWTHffQYTyEspe6VDMy9+r4YbUnoMYquKwKHWjLi YiLgQM1ReNdCMTBx72Gzr6LMYUiDp7msyM8IDJDQXF18hDCGHtNuYcKM7UFlHF0/Aavu ThTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rmm7Ntd1/M38rKLdi8KrFPB93RRenrDKyHORXPxSVKQ=; b=ZxB9U3wN1in7PnpS4Ei4v84BX83LXq37jneZUos6mYBGoOCGVTCYhhC4jnT1m/ts27 aJM+bS+Y/PDwJWIcEVyx8p387JmfJB6Sd3EYOGvSOVVK2s+7ASTozX7YQXZwWEpwZFAO QWDhy/5mp1OAMQcD8V+pFI6LEX2JijuCoFTiFzchSodyKWRuye9hQ6tq3oejBoVniIKA qHpgrPfIX5LrUzAaqDOTk3AxNUUC/LFz/oF9a45oz24HH/0oauN2qxZqDG0J88qBhNsL YUQNrVYQeUg4pshTN9q5pt7FAD5HRqZHGwt0T978fnQfmGTvl2f0IZHZTZ2/uZwhNXTv cyRA== X-Gm-Message-State: AOAM530uiNp2nNlRI7+6KYf6iFOKF+PQbEMs2vCbWFqAB4726TwemPbT Vlyc9OyeT6+ZjPVesrr2BoTvEpWrlIkf6TCZ8euDBWiP X-Google-Smtp-Source: ABdhPJwAprgK8AqniSJtepWOc47UY0IY90saK5vvfrZYLLiiMvXfI4qDU9WbHEbeLM2gIvUGNnwiPl6nKbnxEoXf1IA= X-Received: by 2002:a25:ca08:: with SMTP id a8mr9493520ybg.231.1631828219631; Thu, 16 Sep 2021 14:36:59 -0700 (PDT) MIME-Version: 1.0 From: Giacomo Caironi Date: Thu, 16 Sep 2021 23:36:48 +0200 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000005d9a8905cc239d24" X-Mailman-Approved-At: Thu, 16 Sep 2021 21:39:41 +0000 Subject: [bitcoin-dev] Test cases for Taproot signature message X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 21:37:01 -0000 --0000000000005d9a8905cc239d24 Content-Type: text/plain; charset="UTF-8" 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? 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. If this idea is accepted I will be more than happy to write the test cases for Taproot. BTW this is the first time I contribute to Bitcoin, let me know if I was rude or did something wrong. Moreover english is not my first language, so I apologize if I wrote something awful above --0000000000005d9a8905cc239d24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
recently I have worked on a python implement= ation of bitcoin signature messages, and I have found that there was way be= tter documentation about Segwit signature message than Taproot.
<= br>
1) Segwit signature message got its own BIP, completed with t= est 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 diff= erent BIP only for Taproot signature message exactly like Segwit?

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 pa= ss validation, either it is valid or it is not. BIP 143 in this case is rea= lly good, because it provides hash preimages, so it is possible to debug th= e function and see where something went wrong. Because of this, writing the= Segwit signature hash function took a fraction of the time compared to Tap= root.

If this idea is accepted I will be more than= happy to write the test cases for Taproot.

BTW th= is is the first time I contribute to Bitcoin, let me know if I was rude or = did something wrong. Moreover english is not my first language, so I apolog= ize if I wrote something awful above
--0000000000005d9a8905cc239d24--