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 7D9F3C013A for ; Thu, 11 Feb 2021 07:27:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5F63A6F4E1 for ; Thu, 11 Feb 2021 07:27:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org 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 1J_9Wfo7momt for ; Thu, 11 Feb 2021 07:27:52 +0000 (UTC) Received: by smtp3.osuosl.org (Postfix, from userid 1001) id 9F6066F4F8; Thu, 11 Feb 2021 07:27:52 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp3.osuosl.org (Postfix) with ESMTPS id C33036F4E1 for ; Thu, 11 Feb 2021 07:27:50 +0000 (UTC) Date: Thu, 11 Feb 2021 07:27:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1613028467; bh=GkJi2iUbN765OGGlvHU2m/7Ga7Ua4GNMxeCCE65w1nI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=H4sRqrDZfkBU6Z8k7i3XoLEcMzrEYJvdOkz27IUK6MyHeUVet7UJ1pXBxbwceKyH7 BCD+GGagU01ygp4c+f/EYEemJSwiHxLBvftYNhsaX3oOAfw71tBauH6N2t2z1FmxBz J/U2OBQnLd6RkT4IiKXvZqazlWUFhAA1F1kX4oQI= To: Dmitry Petukhov From: Dr Maxim Orlovsky Reply-To: Dr Maxim Orlovsky Message-ID: <19374944-3B6C-40FC-8E91-4319851E13D9@protonmail.com> In-Reply-To: <20210205230029.4dd6fc4d@simplexum.com> References: <20210205230029.4dd6fc4d@simplexum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 11 Feb 2021 09:05:33 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org 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 07:27:53 -0000 Hi Dmitry, Thank you very much for readying and analyzing my proposal! >> Testnet path is unhardened from this point & till the end of the >> derivation path: no need to prevent private key leak there, >> simplifies test software (hardened paths require private key access >> for derivation). >=20 > I believe this will reduce robustness and will add complexity to the > test software instead. If the derivation path is hardened in 'production > code' and is unhardened in 'test code', then: code paths that depend on > hardened derivation may not be tested; there will be unnecessary > code that will need to deal with 'un-hardening' the paths for test code. <...> > It is OK to require privkey access to hardened paths in test > software, because the same behaviour is expected in 'production=E2=80= =99. You are right, agree > It is much more robust to just change the 'purpose' part of the path, > and leave the rest unchanged. Not sure whether the purpose is the correct place to indicate testnet: in t= his case it we will have to support one testnet per each blockchain type (w= hich is not the case). So probably we should reserve a single dedicated val= ue for any testnet withing ``blockchain` field using hardened path as you s= uggested - for instance, 0xFFFFFFFF may do the job. Kind regards, Maxim