Add bech32 support + on-screen visualization

[jleni]

We would like to add support for bech32 addresses + on screen visualization. This will require the following changes. We can plan for that in this issue.

• [x] Include Bech32 support
• [x] Ledger API (available to gaia-cli / voyager )
  • support to show on-screen the public key for a certain HD path
  • support to show on-screen the bech32 address for a certain HD path
• [x] Adjust corresponding clients
  • ledger-cosmos-go
  • ledger-cosmos-js

Optional:

• Menu options?:
  • This requires a convenient way to navigate account/index, etc. It might be confusing and not easy to manage with just two buttons.
  • public key and address
  • scroll along the HD index?

Open questions The following is an initial list of open questions that we need to address in order to finalize the spec:

• HRP (Human readable part) handling
  • Is the HRP stored in the device or passed in every call?
  • Does the app has a default HRP="cosmos"?
  • How should we deal with different coins sharing the same HD path branches?
  • We assume that pub keys are HRP+"pub", etc.. the postfixes follow the SDK standard.

Looking forward to your comments!

[jleni]

@fedekunze do you have some additional feedback on this?

[cwgoes]

The CLI/REST-side functionality shouldn't be a problem.

Can we make sure this works across networks? I guess setting the HRP every call would be one way to do that - but I wonder if that weakens security somewhat, if an application were to masquerade with another network's HRP. Storing the HRP on the device and allowing it to be set (perhaps with PIN entry) might be better in that aspect. I guess another question is whether we expect users to use the same Cosmos app for several Cosmos networks, or install one app instance per network (in which case we could set the HRP in the app directly, although that would require some cooperation from the Ledger store).

[jleni]

Yes, that was something we discussed with @jackzampolin.

When a ledger app is published, the first X items in the HD path are fixed and restricted by a ledger certificate/signature.

Cosmos networks are not indicated in the HD path, so the cosmos app with access to 44'/118'/.... can sign any cosmos network.

With respect to HRP. We could pass on calls but it is important to keep in mind that:

• network X, hrp: 'netx' path 44'/118'/0'/0/0
• network Y, hrp: 'nety' path 44'/118'/0'/0/0

will share the same public/private keys but their bech32 addresses will look different.

[zmanian]

We largely expect that keys will be portable between Cosmos networks. It's possibly that other chains will keep the same HRPs.

I'm trying to think if changing the HRP is a viable mechanism for an attack. My sense is that the HRP is not an attack surface and it would simplify things for app developers if the app accepts any HRP sent by an app.

[zmanian]

We probably need to have an API that enables send 2 HRPs. 1 for addresses and 1 for public keys.

[jleni]

I thought we could use a base HRP and others are created by concatenating: HRP+"pub", etc.

[zmanian]

I guess that's a safe assumption. https://github.com/cosmos/cosmos-sdk/blob/develop/docs/spec/addresses/bech32.md

[jleni]

As discussed in Slack, only addresses will be shown in the user app.

[jleni]

The first round is ready.

• The latest version of the Cosmos User app support the feature
• Libraries has been updated
• We need to coordinate with @fedekunze the Voyager integration
• I have opened an issue for the gaiacli integration (https://github.com/cosmos/cosmos-sdk/issues/3658)

[jleni]

Update:

• Ledger has received the PR for v1.1.0 https://github.com/LedgerHQ/ledger-app-cosmos/pull/3
• Hopefully this will get published in their app store in the March release
• Integration into gaiacli has been merged https://github.com/cosmos/cosmos-sdk/pull/3670
• JS library is ready https://github.com/ZondaX/ledger-cosmos-js/pull/9
• Voyager integration is pending https://github.com/cosmos/voyager/issues/2130

I would advise closing this issue if others agree

[cwgoes]

Agreed (I don't have permissions to close it) - thanks @jleni.