Will we support accounts, and if yes how?

[rbrunner7]

So far Monero implements accounts together with subaddresses in a pretty rigid way, with a two-index system, one index identifying an account and secondary indexes identifying subaddresses within that account. Both numbers are 32-bit unsigned integers. You can read more about accounts as implemented now in the project wiki here.

Seraphis, or better Jamtis, significantly improves on this. The sometimes confusing and quite artificial distinction between primary addresses and subaddresses is gone, and all the addresses belonging to a wallet have a free index coming from a linear space of 16 bytes. That very large space allows to generate any needed addresses simply by choosing an index at random with a small enough chance of producing collisions.

So, if a Seraphis wallet app wants to implement accounts, technically it is free how it subdivides / splits that large space into "buckets" called accounts, and how it maps them to those flat 16-byte indexes. For example, it could "put away" the first million of indexes for up to 1000 accounts with up to 1000 addresses each, so that the fifth address in the second account would map to index 1004, assuming zero-based numbering.

A whole array of questions and potential problems seem to spring up immediately.

That mapping system is not "engraved" in the blockchain anymore obviously; another wallet app is free to use a different partitioning system with up to 1,000,000 addresses per account, and uppon restore will put all the addresses created in the first wallet into a single account, which the user probably won't see as a good outcome.

Somebody generating addresses for a wallet at random, e.g. a shop system, will generate addresses with indexes that won't fit into any such primitive index partitioning system, be it with accounts for 1000 addresses or 1,000,0000 addresses each, which leads to the question how to present those addresses to the user in the wallet.

And you could ask whether accounts are really "worth it", whether they are useful enough for users, and easy enough from them to handle, to justify the effort needed to implement them. I am not aware about complaints along the line "This smartphone Monero wallet is nice, but I really miss the accounts offered by the CLI wallet".

Maybe in the light of all these questions and in the interest of a good wallet modularization a workable approach would be one that @UkoeHB proposed in a first discussion about this: Keep accounts out of the core Seraphis wallet, but make everything flexible enough that they can get added later in an easy and technically elegant way.

[tinyvoice]

Summary: Accounts are useful, even very important, for day-to-day use of Monero. How they are implemented may be debatable, but I would very much like there to be some sort of Account system within wallets.

"This smartphone Monero wallet is nice, but I really miss the accounts offered by the CLI wallet". For me, I don't have this complaint because all the wallets I use have accounts built in, as it is that important to how I manage things. GUI, CLI, Feather, Cake - all have it. Accounts are pretty important for the way I use and segregate Monero, and without them, I'd be juggling a lot of wallets. I feel that the official GUI/CLI losing accounts would be noticeable loss of real-world functionality.

I think UkoeHB's proposal is good for getting things off the ground, but I think setting a standard for how to segregate the addresses into accounts would be important at some point. At least as a foundation and for other wallets to follow suit, it may be beneficial to define a "default" subdivision of addresses to accounts, such as your 1000-address example, perhaps with the freedom for wallets (or maybe even users) to change that default to, for instance, 5000-address accounts or something. It's nice to have the freedom for different wallets to define things differently, but that doesn't mean it's not useful for the official wallet to have a basic setup for this. Even if a restored wallet dumped all funds into one account, I think that would still be better than having no options to have accounts.

P.S. Thanks @rbrunner7 and the rest who are working on Seraphis/Jamtis! You're all heroes of freedom.

[rbrunner7]

I was thinking about this quite a bit and came up with the following proposal:

What seems already pretty much set in stone is the fact that whatever Seraphis and Jamtis capable wallet apps do or don't with accounts, accounts won't automatically restore from info recorded in the blockchain because they are not part of the protocol anymore, so to say.

We should not take this as a reason for lament IMHO, but see the big advantage that this brings: We are completely free how to design and implement accounts.

So I went back to basics and asked myself: What is an account, at its core? The answer seems to be: An account is a group of addresses that belong together. You can display them together of course, and they play an important role when selecting enotes that go into transactions, as you mostly avoid transactions that span several accounts.

This sure does not need something like indexes, decisions how many addresses can maximally go into an account, or similar. There should be no restrictions which accounts a particular address can or can't go into, and we certainly don't need any such restrictions for accounts to work properly.

All we need are lists that tell "These addresses belong to this account", period.

Maybe, at least from a technical point of view, we even don't need the requirement that every address has to belong to a certain account: Why not have wallets with e.g. 3 accounts and a handful of addresses that just stand alone?

Also at least technically nothing speaks about letting users freely move addresses between accounts, or even completely re-arrange them into new accounts. I am not sure that this would even be relevant in any way regarding "privacy" and "leaving traces on the blockchain" as I think it can be now because of the index info in the blockchain.

If you create a new address, it can go into any account, e.g. the "current account" if the wallet app implements such a notion, or also left to stand alone. Likewise if you receive an enote to a new address, you can freely tell the wallet app to put it into any of the existing accounts, or again just leave it stand alone.

If you restore a wallet with pre-Seraphis enotes it seems sensible to create accounts based on the account info as recorded in the blockchain, but those will nevertheless be "free accounts" in the sense described here, with all the freedom that they bring: The indexes of those enotes will play no role anymore after restore.

[rbrunner7]

There is a quite lively and extensive ongoing discussion about accounts and their implementation in the Jamtis "gist", starting around here.

[rbrunner7]

The idea that I described here earlier, to allow fully free associations of addresses to accounts in the wallet, leads to something that I called private wallet data in issue #39 - data that is only stored in the wallet file and that you can't restore from the blockchain using your seed.

The mentioned issue #39 could offer a partial solution for this problem, making it easy to transport the account configuration between wallet files / wallet apps. You need of course the foresight to save the data into a transfer file of course.

[UkoeHB]

Free association of addresses would probably only work for user wallets where the number of accounts is relatively small. Recording a flag that points to a given segregation strategy would be more general. You could even have a variant field for segregation strategies with different custom data fields per type (e.g. for account labels for user wallets).

[rbrunner7]

Free association of addresses would probably only work for user wallets

Correct. My current point of view is that we have to care only about "user wallets".

In my assumption large players with special requirements will do whatever they like, and make sure themselves that their software supports that, so all is left for us is to care about the "little people". And if we give those a fully free way to group addresses into accounts, they should never have any real problem where something is forced upon them that they don't want. Whatever index comes in, however produced, does not matter, the address can go into any defined account.

I see more than maybe half of all Monero users that never bother to use accounts because no need. From the half that uses accounts, maybe again half will deal with an absolutely trivial number of accounts, merely a handful. You are left with power users, maybe 1/4th of all users, that have a "non-trivial" amount of accounts and addresses in them, where things still have to work, but where operations are allowed to take a few seconds, and files like I proposed allowed to get quite large - power users will deal with such things.

[tinyvoice]

In issue #770 on monero-project, four options were mentioned for account/address subdivision.

To preface, I find it important that, at least for non-fringe use-cases, we make it such that restoring from a mnemonic seed does not inherently destroy a user's fund segregation, as this could be very detrimental for financial/record-keeping and privacy reasons. When I restore from seed, I expect my funds to remain safely separated, but I don't feel so strongly about it that I think baking this into the core protocol is necessary.

Why can we not do a combination of options 1 and 2 mentioned at the 2022-12-19 meeting (have a default sub-division akin to what @tevador proposed , like an "industry standard," but also allow users to deviate and customize the subdivision fully)? I am concerned with the proposal of fully relying on local storage to keep up with accounts as users who restore funds on a different device will find funds mixed together which were supposed to be separate. Often, to move funds from one device to another, the only thing used is the mnemonic seed, especially if a mobile device is involved. Adding the requirement to copy a wallet file will likely eliminate the option to transfer account data to some new devices, practically speaking, so I'm not in favor of only doing option 2 with no default index. Various wallets adhering to a "standard" subdivision of addresses to accounts would allow the average user to have proper fund segregation when restoring on a new device from seed without needing to transfer a wallet file or store extra bytes on the address or mandate anything on a protocol level. I don't see why we could not do this and also allow "power users" who understand the consequences to customize address-to-account indexing or enable free association of addresses. In those "advanced" cases, it would be more likely that the user would understand the importance of copying the wallet file. If addresses are not mandated to be divided in a certain way on a protocol level, then it should always be possible for a wallet to arrange and re-arrange addresses into various accounts, no? Is the reason to drop the free-association option that it would never be practically needed? But even if we did option 1 only, people could certainly create their own wallet software which allowed for custom indexing, right?

So I guess I'm not sure what makes options 1 and 2 mutually exclusive.