nodiesBlade
commented
2 years ago Here's what a non standard partial derivation path might look like for Pokt to derive the private key:
m/44'/635'/_
i.e:
- m/44'/635'/0
- m/44'/635'/1
- m/44'/635'/2
Open nodiesBlade opened 2 years ago
nodiesBlade
commented
2 years ago Here's what a non standard partial derivation path might look like for Pokt to derive the private key:
m/44'/635'/_
i.e:
Is your feature request related to a problem? Please describe. This feature would allow users to create/copy 24 seed phrase and import it into the web wallet (and other wallets) allowing them to derive multiple wallets from a parent seed. (Similar to Meta Mask, Ledger, etc).
Edit: Looks like the pocket keybase also uses a bip39 seed
This could be beneficial for anyone who needs to simplify key management (and probably securer too, depending how node runners/app runners are storing keys rn at scale)
Describe alternatives you've considered This can be an addition to generating a private key / encrypted ppk.
Additional context I know the ledger application is in development, so I believe we should stick to their standard (which is most likely a non-standard partial derivation path). Defining the standard will help pave on which standard to adopt so we don't end up with multiple. I've seen such multiple standards such as as (i.e "old", "ledger", etc) which uses a bip32/39 strictly resulting in confusion.
Most BIP32 algorithm implementations derives from Secp256k1. Since private keys (from what I've seen in the Core code so far) are derived from ED25519, I'll have to do some further research on this - did see some references to Secp256k1 in the forked tendermint code..
https://github.com/solana-labs/solana/issues/6301 and SLIP-0010 starts as a good initial starting point. Slip-0010 looks perfect from an initial read, it supports only hardened paths which is what most of us needs.