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

Restoring from Keys should be more explicit. #872

Open
juanpc2018 opened this issue Nov 8, 2022 · 4 comments
Open

Restoring from Keys should be more explicit. #872

juanpc2018 opened this issue Nov 8, 2022 · 4 comments

Comments

@juanpc2018
Copy link

juanpc2018 commented Nov 8, 2022

for example:
cake-tech/cakewallet monero.com
has:
View & Spend Keys, Public & Private = 4.
but m2049r/xmrwallet monerujo only has 2 Private + public address,

xmrwallet restore from keys should clarify:
View Key Private:

Spend Key Private:

for people moving from other wallet to xmrwallet, to avoid human error or wasting time.

@chaserene
Copy link

I agree. in places where a view or spend key is referred to, it should be specified whether it's a public or a private one. this includes places such as:

  • opening screen -> "+" -> Restore view-only wallet
  • other wallet creation/restoration flows
  • wallet screen -> "⋮" -> Show secrets!

@m2049r
Copy link
Owner

m2049r commented Jan 13, 2024

@anhdres ideas?

@anhdres
Copy link
Contributor

anhdres commented Feb 5, 2024

Are we talking about adding the word Private to every instance of View Key for consistency and teaching the user that they should not share it as if it were an address?

As in here for example?
photo_2024-02-05_19-18-39

If that the case, I don't see why not. It would read:
Public Address
Private View Key

We should probably even say Public 4.. Address or Public Base Address or whatever it's properly called. Or not, since technically every other address is called a subaddress. God knows I think we should all stop using 4.. addresses in every wallet, and then just call subaddresses addresses because it fucks with every new user's head.

@chaserene
Copy link

chaserene commented Feb 7, 2024

@anhdres Monero (in its current CryptoNote paradigm) has both public/private view keys and public/private spend keys. (good explainer by dEBRUYNE here.)

places in the wallet where I encountered them:

  • opening screen -> "+" ->
    • Restore view-only wallet: private view key
    • Restore wallet from private keys: private view key, private spend key
  • wallet screen -> "⋮" -> Show secrets! -> Detailed information: private view key, private spend key

in a popup/tooltip I also encountered the term "secret" instead of "private" for a key, which isn't wrong, but for clarity I would stick to public/private. this is also the terminology in Zero To Monero.

I would avoid calling an address public. addresses are by definition public (in the sense that they have to leave the wallet if you want to receive transactions from others), and there's no such a thing as a private address. so it would make sense to call 4... addresses primary address wherever they occur. (Zero To Monero sometimes calls them main addresses, but I haven't seen that anywhere else ever.)

and yes, we should definitely stop using primary addresses wherever possible, and just call subaddresses addresses. the distinction creates behavior that damages privacy (reusing the primary address because it seems more certain/official). you could remove it from the list of addresses people can receive to (Feather has already done this). however, I don't think you can get rid of it when exporting view-only credentials or creating a view-only wallet. that's because to generate subaddresses you also need the public spend key (Ks), and that's by convention transferred in the form of the primary address (Kv, Ks). you could start accepting/displaying only the public spend key instead, but people who want to import from or export to other wallets would be in trouble.

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

No branches or pull requests

4 participants