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

Staking use sdk.AccAddress instead of sdk.ValAddress #1910

Closed
4 tasks
faboweb opened this issue Aug 2, 2018 · 10 comments · Fixed by #2040
Closed
4 tasks

Staking use sdk.AccAddress instead of sdk.ValAddress #1910

faboweb opened this issue Aug 2, 2018 · 10 comments · Fixed by #2040

Comments

@faboweb
Copy link
Contributor

faboweb commented Aug 2, 2018

Summary of Bug

Most of the validator addresses are declared as sdk.AccAddress instead of sdk.ValAddress is that on purpose? sdk.AccAddress has another bech32 prefix then sdk.ValAddress and I would recommend using the latter.

Steps to Reproduce


For Admin Use

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

Related to #1902

@cwgoes
Copy link
Contributor

cwgoes commented Aug 2, 2018

Related to #1902

Maybe - isn't this just caused by the current implementation which references validators by owner address (which is an AccAddress) and thus requires knowing the validator owner address for most delegation-related commands?

@rigelrozanski
Copy link
Contributor

yeah it's related because we want to use Val Bech32 on the owner address just to not confuse delegators as per a series of community discussions. Simultaneously we want to switch all use of the Val Bech32 to represent this owner address (just bech'd with val in the address) and not the Tendermint Validator signing address - nothing in in the Gaia CLI (except maybe an advanced user suggestion or two) should be using the Tendermint validator signing address

@zmanian
Copy link
Member

zmanian commented Aug 3, 2018

Please update this spec if you make any changes to the semantics of bech32 prefixes.

https://github.com/cosmos/cosmos-sdk/blob/develop/docs/spec/other/bech32.md

@rigelrozanski
Copy link
Contributor

rigelrozanski commented Aug 3, 2018

@zmanian thanks for the link! - yeah I'd propose the following changes:
Existing cosmosvaladdr/pub -> cosmosconsaddr/pub
Then reuse cosmosvaladdr to represent operator (aka. "owner") address of validator

@faboweb

Most of the validator addresses are declared as sdk.AccAddress instead of sdk.ValAddress is that on purpose? sdk.AccAddress has another bech32 prefix then sdk.ValAddress and I would recommend using the latter.

It was on purpose - the index is supposed to be the validator operator (aka. "owner") not the Tendermint signing key which is what sdk.ValAddress is currently bech'd too. I think we were missing another bech key here which is "signing" key which is to mostly be used in the back end and rarely referenced by users (pretty much only during validator creation / changing the Tendermint key) - if we introduce this distinction I think we alleviate a lot of confusion the community is having

@cwgoes
Copy link
Contributor

cwgoes commented Aug 3, 2018

I think "validator owner address" is a sufficiently important distinction to merit its own prefix which isn't used for anything else, and that we should then use a new prefix for Tendermint signing keys and associated addresses (not entirely sure if that's what you're proposing @rigelrozanski).

@rigelrozanski
Copy link
Contributor

@cwgoes -> yes your statement is exactly what I was attempting to say :)

@faboweb
Copy link
Contributor Author

faboweb commented Aug 3, 2018

Thank you for the clarification guys.

@zmanian
Copy link
Member

zmanian commented Aug 3, 2018

How does a user find out their validator owner address?

They can't just change the prefix on what they see in gaiacli keys list cause the prefix is included in the crc bits.

@cwgoes
Copy link
Contributor

cwgoes commented Aug 5, 2018

How does a user find out their validator owner address?
They can't just change the prefix on what they see in gaiacli keys list cause the prefix is included in the crc bits.

Good point - we'll need to add an additional command for this purpose, or perhaps a flag to gaiacli keys list.

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

Successfully merging a pull request may close this issue.

4 participants