From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8C432C013A for ; Thu, 11 Feb 2021 20:31:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 76B8D86E71 for ; Thu, 11 Feb 2021 20:31:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8twx9O29QZtJ for ; Thu, 11 Feb 2021 20:31:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 9AD1E86E56 for ; Thu, 11 Feb 2021 20:31:24 +0000 (UTC) Date: Thu, 11 Feb 2021 20:31:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail2; t=1613075482; bh=h0s7r3RrY8bZRSLiCneWFh0Rtpyt2DnssnhIUI+aSms=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=j25wUWwa2/Dw6cAXBrnDsXLwbZv4RkzKjCb9ILUZZshMs79SXQnoNviR1hW/+y0oV VjXNj1lSh+azEeJG4GnzhezCSpgfDg2c1NBw2vFBf25eFaeEfxGlUTUbKsnL5FDrRs /pKCw4eiNqswUrqqi0K6dL9P4CK++kqsfqkjScA5xtPxZkNJTfMtjPwtgjaavodZAl NOquizDoIzrfVFDRNwv8aFgMOKsFhVl3USoyL0YuGBhsfnr3O9ifkWnmo/93gTw9uP MmvkDYM+uODHMCAWMGnGNZxoJug+GbIr2pcjGEllC7P8Uk/wexrWJonydbN4BPALRk N92wpsdjmxsYw== To: Dr Maxim Orlovsky From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: <5096768E-3A77-4CD8-AC22-105CA63152A7@protonmail.com> References: <5096768E-3A77-4CD8-AC22-105CA63152A7@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity 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, 11 Feb 2021 20:31:26 -0000 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky wrote: > Thank you very much for all the clarifications; it=E2=80=99s good to have= them sorted out and clearly structured. From what you wrote it follows tha= t we still need to reserve a dedicated purpose (with new BIP) for BIP340 si= gnatures to avoid key reuse, am I right? Maybe, but it would be for a particular way of using keys (presumably: sing= le-key pay-to-taproot), not just the signature scheme itself. If you go dow= n this path you'll also want dedicated branches for multisig participation,= and presumably several interesting new policies that become possible with = Taproot. The only thing ECDSA/Schnorr specific about this is that - if you want to m= aintain provable security - the keys used for ECDSA and BIP340 should be se= parated by a hardened step. It seems however that all approaches people act= ually use to prevent reuse do that already. And as I said, dedicated branches only help for the simple case. For exampl= e, it doesn't address the more general problem of preventing reuse of keys = in multiple distinct groups of multisig sets you participate in. If you wan= t to solve that you need to keep track of index is for participating in wh= at - and once you have something like that you don't need dedicated purpose= based derivation at all anymore. So I'm not sure I'd state it as us *needing* a dedicated purpose/branch for= single-key P2TR (and probably many other useful ways of using taproot base= d spending policies...). But perhaps it's useful to have. Greg Maxwell pointed out to me that there may be another reason to want non= -reuse across ECDSA and BIP340 keys: if someone were to do all of these wro= ng: * not follow BIP340 and re-use RFC6979 for BIP340 nonce generation * reuse the same keys for both * sign the same message with both ... you would actually leak your private key. This isn't a concern for Bitc= oin transaction signing however, as the sighash (message) indirectly commit= s to BIP341 or not, and thus it'd be impossible to construct colliding mess= ages. Still, it's a consideration to factor in. Cheers, -- Pieter