Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id CAECDC000D for ; Wed, 6 Oct 2021 20:36:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B933B4022F for ; Wed, 6 Oct 2021 20:36:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zx_qfyMq1MOs for ; Wed, 6 Oct 2021 20:36:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by smtp2.osuosl.org (Postfix) with ESMTPS id 34B7940111 for ; Wed, 6 Oct 2021 20:36:03 +0000 (UTC) Received: by mail-yb1-xb2d.google.com with SMTP id a7so8332898yba.6 for ; Wed, 06 Oct 2021 13:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n6D+mvgLl6dyfGnrvOlgXu+R7bdgJjM6WWWkG3Si5yw=; b=i0vjiJmhIHroN4Zp0PwT2vn2PNdw30YDrppoBMIiM3kLWzPxT0oSiu9lmHzoKQtNFl 2iqGxBQWdKgky+h+NjiiLrajJHgXAGbAX4QJWuxsLv2EMilrzZxiHpa2seXWfdSLtC/N sZrUrqPFuNvqtbqEcujiSywjLNdlQEelDfk7PD64goKsTJ2k+Vr/C1UkJWGLdkh85T4B pcGGF8r1ZYWMDLEnb18Rzibaso9lQ0sJTSzmQtcJSCea0aVVSTxY6I2a92da411UW4by HrI0lmJU/xc3Fyq7uAopSTOrLI52CmchW6/5zCuSkNtwjTH4MlMYzDOKkFmunlGbBYfp syKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n6D+mvgLl6dyfGnrvOlgXu+R7bdgJjM6WWWkG3Si5yw=; b=7BBwW26ovh1jMo9w/PCALs2/QFphCi643It4x7pAKCIO4pzZOjPdGQwoOfXVbYfKBS 2UnNO0k8GSIeHKaO0BXCNBGFSrsypN8BrpGr21Nt40gnzt+7dc9uzZ15zsyTINs2F8yG SxNefNa8NhauiwUmC0uFKTZMCnQ1FfVaeHSLYCfsvKWRfC7QBiEkUbuGziTJTuDo2FAV 17GeNnVJhuDlI4xaq9GNPQkirarfIg1jvWwSjVO6+BOe/ULx4wa1ea+0vHV2ZopqGhDX 4JhGTcbqTW/VmjMx8rPIHVLFBQAf8iq3OhabU91cqr0fndNzaZz3u8DoHtFi6sb1QtAg Sn4Q== X-Gm-Message-State: AOAM532UO6r/qeLp1I5ubxtwpoTRE/fQe5xAMEXbA5l3EOZ+8NiGr1wQ D9QUgYj1FG6aMLiA59NQvb02j4IlTUD84APQoSh9aNRRd/kbYQ== X-Google-Smtp-Source: ABdhPJwAGrBh8ChK5/vmQhBtXkKClvKOKb3oVcTkU7gqyQxVmIPhaprkv/IV3L3uF+VTUKss5dbTAo75pfyMT12401A= X-Received: by 2002:a5b:145:: with SMTP id c5mr337297ybp.60.1633552562144; Wed, 06 Oct 2021 13:36:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Giacomo Caironi Date: Wed, 6 Oct 2021 22:35:51 +0200 Message-ID: To: bitcoin-dev@wuille.net Content-Type: multipart/alternative; boundary="00000000000030483f05cdb5180e" X-Mailman-Approved-At: Wed, 06 Oct 2021 21:01:11 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [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: Wed, 06 Oct 2021 20:36:04 -0000 --00000000000030483f05cdb5180e Content-Type: text/plain; charset="UTF-8" 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 > . > 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 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 >> >> --00000000000030483f05cdb5180e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The related pull request is now open=C2=A0https://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=C2=A0here. They cover most of the SigMsg function but = they don't cover the ext_flag, so they are only for taproot key path; b= ut if you want to test for script paths you have to implement more than thi= s function so you would use the official test vector.
Could someone ple= ase take a look at them? I think that they are right but I am not too sure<= /div>

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 bit= coin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
Hi,=C2=A0
rec= ently I have worked on a python implementation of bitcoin signature message= s, and I have found that there was way better documentation about Segwit si= gnature message than Taproot.

1) Segwit signat= ure message got its own BIP, completed with test cases regarding only that = specific function; Taproot on the other hand has the signature message func= tion 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 sig= nature message exactly like Segwit?

I'm not entirely sure what you mean; you're saying BIP 341= twice.

Still, you're right overall - ther= e 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 documentat= ion/vectors can't be improved in the existing documents.
=
2) The test vecto= rs for Taproot have no documentation and, most importantly, they are not at= omic, in the sense that they do not target a specific part of the taproot c= ode but all of it. This may not be a very big problem, but for signature ve= rification it is. Because there are hashes involved, we can't really de= bug 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 has= h preimages, so it is possible to debug the function and see where somethin= g went wrong. Because of this, writing the Segwit signature hash function t= ook a fraction of the time compared to Taproot.

You're right. The existing tests are really intend= ed 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 th= at generates them (https://gi= thub.com/bitcoin/bitcoin/blob/v22.0/test/functional/feature_taproot.py#L605= L1122) is probably better at that even, but still pretty dense.

If th= is idea is accepted I will be more than happy to write the test cases for T= aproot.

If you're= interested in writing test vectors that are more aimed at helping debuggin= g 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 inter= nal keys and script trees. I'm happy to help to integrate such in Bitco= in Core and the BIP(s).

Thanks!
=
Cheers,

--
Piete= r

--00000000000030483f05cdb5180e--