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). > > 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’. 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 this case it we will have to support one testnet per each blockchain type (which is not the case). So probably we should reserve a single dedicated value for any testnet withing ``blockchain` field using hardened path as you suggested - for instance, 0xFFFFFFFF may do the job. Kind regards, Maxim _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
