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

Namada Keychain: Discussion to migrate keychain (introducing Proof-Gen keys) #1384

Open
jurevans opened this issue Dec 5, 2024 · 0 comments

Comments

@jurevans
Copy link
Collaborator

jurevans commented Dec 5, 2024

Currently, accounts in Namada Keychain do not have Proof Generation keys. For existing users to access proof-generation keys, they could:

  • Re-import their accounts (not ideal)
  • Namada Keychain provides a one-time update process when the new keychain is released, where the user authenticates, and we append proof-gen keys for each shielded account (probably the easiest solution for users)
  • Generate proof-gen keys on a per-accounts basis, perhaps when they're needed (potentially the most annoying solution)

Also, we should think about how this could work for Ledger as the process is a bit different (since it requires outside approval) - This may be the exception where we ask that they re-import the account, as it's easier than importing a mnemonic.

The migration process (in this case) should only touch type: "shielded-keys", appending the proof-gen keys

  • Authenticate to unlock spending key
  • From this, generate proof-gen keys
  • Append to record

The type: "ledger" accounts will need a corresponding type: "shielded-keys" account entry, where address equals the payment address, and we add viewing key & proof-gen keys, and parentAccount equals the id of the original Ledger account. There could even be a separate import where user selects a Ledger account (to get the path) and they import shielded keys from Ledger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant