Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HD wallets - support BIP32/39/44 #335

Open
nodiesBlade opened this issue Mar 12, 2022 · 1 comment
Open

HD wallets - support BIP32/39/44 #335

nodiesBlade opened this issue Mar 12, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@nodiesBlade
Copy link

nodiesBlade commented Mar 12, 2022

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..

solana-labs/solana#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.

@nodiesBlade nodiesBlade added the enhancement New feature or request label Mar 12, 2022
@nodiesBlade
Copy link
Author

Here's what a non standard partial derivation path might look like for Pokt to derive the private key:

m/44'/635'/<account_index>'

i.e:

  • m/44'/635'/0
  • m/44'/635'/1
  • m/44'/635'/2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant