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

Ambiguity of the term "account" #44

Open
rbrunner7 opened this issue Jan 13, 2023 · 1 comment
Open

Ambiguity of the term "account" #44

rbrunner7 opened this issue Jan 13, 2023 · 1 comment

Comments

@rbrunner7
Copy link
Member

rbrunner7 commented Jan 13, 2023

Through some recent discussions on IRC and on Reddit that produced misunderstandings I became aware that the term account as used in the "world of Monero" is ambiguous and used for two very different things. I consider this as unfortunate and ask myself whether we can take the switch to Seraphis and Jamtis as an opportunity to eliminate this issue.

The term is used in the frame of the mechanism that you can use to subdivide a single wallet into something like sub-wallets: A Monero wallet can contain a number of accounts. The issue #21 Will we support accounts, and if yes, how? here is about those accounts.

But the term is also used for what more often gets called wallet. See e.g. the Moneropedia article Account on the getmonero.org website written in December 2017. Its first sentence:

Those familiar with Monero's predecessors will be more familiar with the term wallet to describe this. In Monero we call this an account, and it is a private account owned and operated by a Monero user.

It has a chapter Multiple Accounts which clearly describes how you can have multiple Monero wallets without problems.

In the Monero C++ codebase there is a class account inherited from the original CryptoNote code. You find its header file here. The class manages the 4 keys that are central to a Monero wallet and is thus clearly on the side of the second use of the term.

It's a bit funny that there is no separate class to manage the accounts that subdivide wallets in the first sense, and if you try to look up how those accounts are handled by wallet2 and simplewallet you probably stumble over the one account class first.

Google seems to treat wallet and account as synonyms, and if you search for "Bitcoin account" also lists pages about Bitcoin wallets that do not use the term account.

How could we avoid this "clash of terms"? There seem to be at least two ways. One way would be to replace account with subaccount whenever we talk about subdividing wallets. Another way would be to search for another name for the Seraphis equivalent of that existing account class, and move away from calling Monero wallets accounts.

@tinyvoice
Copy link

That Moneropedia article is very disconnected from the way these terms are used. It may have been somewhat true at one point, but in current common parlance, most people use "wallet" to describe what Moneropedia is calling "Account." I think the article needs to be altered to reflect how people are really using these terms, especially once Jamtis hits: "wallet" refers to the thing generated from the seed and has a private spend key, and an "account" is a subdivision within that (i.e. an account does not have its own seed and private spend key separate from other accounts within the same wallet).

As far as if we should still use a different word than account (the divisions of addresses within a wallet), I'm a little more ambivalent. We could keep calling them accounts, subaccounts, or we could use something entirely new, like subwallet, subaccount, category, bucket, etc. I think it would probably be easiest for everyone to just keep using the term "accounts." It has the added benefit of being how people discuss dividing funds within their bank - checking account, savings account, etc.

Regarding the code/class names, I'm a fan of naming classes/objects/variables as closely to how we use the names otherwise, so I think we should decide how we want to use these terms from a UX perspective and just let the code reflect that wherever possible.

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

2 participants