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

Better UX for specifying a pubkey when adding keys with the CLI #10388

Closed
4 tasks
shanev opened this issue Oct 17, 2021 · 3 comments · Fixed by #17639
Closed
4 tasks

Better UX for specifying a pubkey when adding keys with the CLI #10388

shanev opened this issue Oct 17, 2021 · 3 comments · Fixed by #17639
Assignees
Labels
C:Keys Keybase, KMS and HSMs T:feature-request

Comments

@shanev
Copy link

shanev commented Oct 17, 2021

Summary

Adding a key via a pubkey requires the user to know internal details of how a key is specified.

Problem Definition

Currently, a pubkey is specified with:

gaiad keys add [name] --pubkey "{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"AtObiFVE4s+9+RX5...\"}"

A user shouldn't have to read code and tests in order to figure this out (like I had to do) and manually enter escaped JSON into the command line.

Proposal

  • Take in a bech32 pubkey by default, just as a string (like before)
  • 99% of chains use secp256k1, so specifying the algo every single time doesn't make sense. It's safe to assume secp256k1 is the default.
  • Use the --algo option for exceptions, and if it exists assume the pubkey is raw. Do the heavy lifting in code. Don't make the user do it.

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@ValarDragon
Copy link
Contributor

ValarDragon commented Oct 17, 2021

I don't think the UX for this is ok imo, we can't have people dealing with escaping JSON for this.

At least for the next several months, you need to be using --pubkey for using multisigs. (Even the multisig UI works requires you to have made one tx from the multisig via CLI before you can use the CLI :/)

cc #10338 as well. Closed that issue in part because we found a hacky workaround via migrate commands, so didn't realize this is this painful.

Can we at least make it so its a bech32 encoding of the underlying pubkey bytes from the base64?

@jhernandezb
Copy link

This will be painful for multisigs, can at least provide documentation on how to migrate to that format?

@amaury1093
Copy link
Contributor

amaury1093 commented Oct 18, 2021

It was decided to remove bech32 encoding of pubkeys, and in the issue linked by @ValarDragon to not restore it.

As a workaround we could:

  • keep keys add --pubkey <JSON> like before (note: no need to avoid escaping JSON, --pubkey '{"key","value"}' works)
  • and also add keys add --pubkey-base64 <base64>, which as @shanev proposed will create a secp256k1 pubkey by default, unless an --algo is specified
  • error if both flags are passed at the same time

?

@tac0turtle tac0turtle added C:Keys Keybase, KMS and HSMs T:feature-request labels Mar 6, 2023
@JulianToledano JulianToledano self-assigned this Sep 4, 2023
@julienrbrt julienrbrt linked a pull request Sep 6, 2023 that will close this issue
20 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:Keys Keybase, KMS and HSMs T:feature-request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants