Date: Thu, 11 Feb 2021 07:27:42 +0000
To: Dmitry Petukhov <dp@simplexum.com>
From: Dr Maxim Orlovsky <orlovsky@protonmail.com>
Reply-To: Dr Maxim Orlovsky <orlovsky@protonmail.com>
Message-ID: <19374944-3B6C-40FC-8E91-4319851E13D9@protonmail.com>
In-Reply-To: <20210205230029.4dd6fc4d@simplexum.com>
References: <D962F4E0-E10F-433D-BFC9-3462A8A9CF7A@protonmail.com>
 <20210205230029.4dd6fc4d@simplexum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures &
	decentralized identity
Precedence: list

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