JIP-5: Secret key derivation

[zdave-parity]

No description provided.

[ggwpez]

Naming is clear now, thanks!

[Sajjon]

Just for the sake of discussion - it is my understanding that this is a "custom" HD derivation implementation supporting Curve25519 (Ed25519), right?

Has using "industry standard" SLIP10 instead been discussed / considered?

The advantage of using that is to be compatible with e.g. hardware wallets such as Ledger and Trezor.

However, @zdave-parity has on Elements explain a bit more and maybe SLIP10 is not suitable here.

[zdave-parity]

Just for the sake of discussion - it is my understanding that this is a "custom" HD derivation implementation supporting Curve25519 (Ed25519), right?

Has using "industry standard" SLIP10 instead been discussed / considered?

The advantage of using that is to be compatible with e.g. hardware wallets such as Ledger and Trezor.

However, @zdave-parity has on Elements explain a bit more and maybe SLIP10 is not suitable here.

SLIP10 appears to be pretty similar to this, but does not support Bandersnatch AFAICT, so is not directly usable.

FWIW this key derivation method will never be required; the derived public keys are completely unrelated so it could not be. The point of a standard derivation method is just to make it easy to switch validator impls while keeping the same secret keys. This is particularly useful for testing, but could potentially be useful in a production setting. In the case where the secrets are stored in a hardware "wallet", and there is some flexibility in how the public keys are derived, it may be useful to standardise that. But it seems to me that is likely to be device-specific. In any case I think it's out-of-scope for this particular JIP.

[danicuki]

BLS keys won't be part of JIP-5?

I also suggest to explicitly explain that we can generate scalar secret by applying sha512 to the hashed key:
Seed -> hashed -> scalar

Bandersnatch library can directly take the scalar seed and return the key pair.

In case of ed25519 the secret key is the hashed seed. In bandersnatch no, which causes a bit confusion.

[zdave-parity]

BLS key derivation will be specified, I just haven't looked into the details yet. The BLS key will only be used for BEEFY AFAIK, and the network protocols for that have not yet been defined.

I also suggest to explicitly explain that we can generate scalar secret by applying sha512 to the hashed key

This is covered in https://ed25519.cr.yp.to/ed25519-20110926.pdf for Ed25519 and appendix A.1 of https://github.com/davxy/bandersnatch-vrf-spec/blob/main/specification.pdf for Bandersnatch. Both of these are explicitly referenced, with the terms defined in this JIP linked to the terms defined in the docs. If you think this can be clearer, please suggest a concrete change. I don't particularly want to repeat the contents of either doc in this JIP though.

In case of ed25519 the secret key is the hashed seed. In bandersnatch no, which causes a bit confusion.

Please note that ed25519_secret_seed is also passed through SHA-512 to produce a secret scalar, as documented in https://ed25519.cr.yp.to/ed25519-20110926.pdf. The difference is really just that the Ed25519 document refers to ed25519_secret_seed as a "secret key" while the Bandersnatch document refers to bandersnatch_secret_seed as a "seed". There's not much I can do about that.

[ggwpez]

I would vouch for this getting merged, as there was enough time to voice concerns.