meeting 2hrs: monero-project/meta #649

another thing to discuss in the meeting: gist.github.com/tevador/50160d160d2…52ae02eb3d17024#gistcomment-4026264

meeting time: monero-project/meta #649

1. greetings

hello

Hi

Hello

Hi

hi

howdy

2. discussion; today I want to discuss this gist.github.com/tevador/50160d160d2…52ae02eb3d17024#gistcomment-4025357 and the following comment gist.github.com/tevador/50160d160d2…52ae02eb3d17024#gistcomment-4026264

Anyone have thoughts/comments/questions other than tevador and I?

On method 3: account keys must be pre-computed, meaning "account"-level subaddresses (i) would need to be pre-loaded in a lookup table? I didn't have enough time to fully grok that method

(for non-change/self-spends)

not subaddresses, the account key itself (used to generated addresses for that account)

Do I get that this can be seen as a quite broad question / decision of how to support accounts under Seraphis / JAMTIS, and if yes how?

Basically users would have to tell their software which accounts to look in for funds.

rbrunner: the follow-up comment is about whether/how to support accounts. The original post is about how to efficiently map outputs to addresses/accounts when scanning.

rbrunner: it's more about optimizing output recognition (which accnt/addr the output belongs to)

but there can be tons of account keys, which has a similar issue as method 1 where you need a lookup table, no?

Yeah, but if you basically get rid of rigid account schemes, that does not matter so much anymore, or can get simplified, right?

jberman[m]: hence my proposal to remove the account keys

after listing the pros and cons, I think it's a no-brainer, but I'd like to hear opinions

As far as I can see use of accounts has stayed pretty much a "power user" feature, not even all wallets support them, they are not exactly a roaring success story if you want to be brutally honest

jberman[m]: yes, but at some point the purpose/utility of an 'account' becomes lost if you are generating a lot of them; realistically, the set of accounts should be strictly bounded

Thus if we can simplify there, why not?

yes, we also proposed slashing the account index to 16 bits

rbrunner: it was mostly for merchants

I think accounts should either be fully supported, or not at all.

Interesting. Did it succeed there? Do we know?

but even without account-level tiers, there is still one tier that can generate addresses, but cannot see outputs

I have no idea how people or merchants use accounts currently

Although on second thought, maybe partial support would be ok... if users want to categorize their funds somehow, 'accounts' is the most reasonable way.

I think accounts are a wallet-level feature

Well, at least I have not seen a building up of pressure "When will you finally support accounts?" for wallet that don't support them (yet)

Yeah, but the reference implementation will probably be 99% of users

still, it's probably cleaner if the address specs are agnostic to that feature

I think deprecating "accounts" needs feedback from more users. I use them and it's nice because I get streamlined bookkeeping and a nice abstraction for how funds are spent, without needing to go a deeper level and actually select which outputs I want to spend

Not sure, I think Feather Wallet has made inroads compared with the GUI, and I think they did a conscious decision to not support accounts, because too complicated UX wise

Yes, that's why I liked the approach in the latest comment of a uniform address space that only the wallet logically manages in some "compartments", however you call them

If that really flies

I think the main question today is if 8 bytes longer addresses and 8 bytes larger outputs are worth the optimization of output detection

Maybe we can keep accounts with the simplified scheme but rename them to like 'balance categories' or something to reflect that they aren't 'hard' delineations in the wallet.

BTC and several other coins have accounts as well. From my observations, accounts are rarely used. Part of it is a chicken-and-egg problem. Wallets don't support them since users don't use them, and vice versa.

My personal opinion is that 8 bytes is a pricey worthy of robust output recovery.

Maybe merchants and exchanges are using them, though.

price*

What do you mean with "output recovery" exactly?

view scanning

Rucknium[m]: I have like 10 wallets since I didn't understand accounts at first

With a subaddress table you can have outputs outside the table (this prevents PID address mapping, and similar schemes).

One of the numbers in the BTC derivation paths for BIP44/49-compliant wallets is for account numbers.

And with 8 bytes those "outside the table" problems are (forgive the pun) off the table i.e. solved?

Right; another example: 'generate random subaddress' without needing to know all the subaddresses you already generated

good pun rbrunner

Everything that simplifies has my immediate sympathy :)

(with 'generate random' and 40-bit addresses, a collision will occur 50% of the time over 1mill generations)

I think the output scanning layer would simply return "this output goes to this 56-bit index" and the higher layers would interpret that somehow (could even be a flat 56-bit address space)

right

Is it 40 bit if we keep a reasonable number of fixed accounts?

40 bit with 16bits of accounts

Ah ok

or 'categories' maybe ^.^

One of the nice aspect of today's account is that they restore from the blockchain. If we loose that seems to me we devalue them quite a bit. But can't have all, I guess

^ that aspect would not be lost

Even with a flat space of 56 bits?

On the lowest level

you don't lose anything, that's just a different interpretation of the same data

you could treat the 56 bits as 16+40 bits and get accounts

Hmm, yes, but this may then - at least potentially - differ from wallet to wallet.

I mean wallet app to wallet app

the reference implementation sets the standard, and it is up to other wallets to follow/go a different way

one thing is what is written in the specs, actual implementation is another thing

So if we kept 16 bit "accounts"/categories, the client would precompute 2^16 keys and keep them in memory, right? And if accounts are deprecated, this isn't necessary?

wallets already have the freedom to do something different with indices (not that any of them do, afaik)

jberman[m]: exactly

jberman[m]: that is an option, though imo only categories the user manually adds should be precomputed

Or if accounts are pushed one or two levels up the processing hierarchy, if I understand correctly

the point is that if the account index is used for key derivation then accounts become mandatory for all wallets

It would take 2.6s to set up Blowfish contexts for 65k keys.

are collisions possible today too? or would that be new

collisions where/

possible within reason

That you can find two pairs (account, address within account) that result in the same subaddress?

<UkoeHB> "(with 'generate random' and 40-..." <- here

with 64-bit PIDs, collisions are possible if you have 100+ millions of them

yes generating a random 32-bit subaddress index will also have collisions

with 32 bits, you will get collisions with ~thousands

Because the reach the same ECC point or whatever within the precision used? Or something like that :)

it's extremely unlikely that two different addresses will have the same key

It is just an index that is random, not the ECC point

Anyway, if we also can have collisions *with* accounts, that's not a definite pro of them.

If you randomly generate the same index twice (collision), then you'll get the same adddress

No, I mean whether you can number through all possible accounts and all possible address within them and never get the same subaddress twice

with a guarantee

yes, the set of all possible addresses won't contain collisions except with negligible probability. You need 2^128 random ECC points to get 50% chance of collision.

Ok, so probably not in this universe anymore

who's generating random subaddresses and why does a collision at the index matter? users increment them

I think that was one argument merchants used against subaddresses, "you can generate PIDs at random"

I mean if you forget how many addresses you have. Or maybe you have some service generating addresses for you and don't want them to collide with addresses you generate on your own machine.

I think that would just be a particularly easy implemenation for merchant system, because they don't have to "slog" around info where they stand with the counter

So we have now possible collision rates for random subaddresses on the table which are a bit uncomfortably high, seems to me

that strikes me as not-so-robust today

rbrunner: slog = schlepp?

with the encrypted address tags, merchants could generate indices randomly, but they would still have to check for collisions. I think even with PID this is required unless you have just a few orders overall

Btw in the future we might hear complaints that 40-56 bits is too small for PIDs... don't you need like 10-16 bytes for robust PIDS?

Yeah, "schlepp"

ideally merchant system would use a shared counter to generate addresses

with the lookup table based search, a shared counter is a requirement

My head hurts, with so many conflicting pros and cons ...

Difficult decisions

what are the conflicting things? the only con to 'make a change' is the addition of 8 bytes to outputs/addresses

Well, if that does not open the way to successfully generate random subaddresses without fear / checking for addresses, that's maybe a con?

one thing that's nice: I think method 2 is inferior to either method 1 or method 3, so that one can be eliminated to reduce decision surface

there are two things we are discussing: 8 bytes for more robust output discovery, whether/how to deprecate accounts (a basically unrelated question)

jberman[m]: you mean method 1 is inferior to 2 and 3? 2 can do the same thing as 1, but adds more options

rbrunner: maybe you'd like to propose going to 16 bytes (we need a multiple of 64 bits with blowfish, unless we can find a good 32-bit cypher and can do 12 bytes)?

16 bytes is overkill

I just mean to reduce collision rates*

that's a lot of blockchain bloat just to make merchants spend a bit less on development

collisions are possible across any scheme we're looking at, no? I don't see how in any scheme, someone can without fear successfully generate random subaddresses without checking for collisions

I think I have through the info in the gist more thourougly than I did so far, I suspect I have some gaps in my understanding

I don't think avoiding collisions when randomly generating wallet addresses should the the goal.

tevador: good arguments IMHO

tevador: I agree

Maybe that possible goal turns out to be a mere detraction

But then again, if people generate subaddresses, say, "sensibly", how robust must our output discovery be?

Will we ever not catch one?

Realistically

AFAIK the github repo gets a lot of issues like "wrong wallet balance" etc.

all of that would be gone with this scheme

True, like Reddit, but at least there I have the impression it's almost simply restore height.

And not people fooling around with "exotic" subaddresses, far out or otherwise

here's a recent one: monero-project/monero #8138

I think the added cost of 8 bytes per output for robust subaddress discovery is a solid cost

Which could solve with just using suitable startup parameters?

And deprecating accounts is something I'd imagine would need community feedback on

we don't want to deprecate accounts, that was never proposed by anyone AFAIK

well everything needs community feedback obviously, but more knowledge on how accounts are used from community members would help

'suitable startup parameters' will always be a hacky solution prone to edge cases

Sure, but if I understand correctly there are ways to keep accounts and still simplify things like key generation / handlich right?

the proposal was to deprecate account-level wallets in jamtis

e.g. I can create a wallet that can only access account number 1

Ah, now I understand that. That does sound like a little overkill, at first hearing.

IMHO

what is overkill?

Was my comment not clear? gist.github.com/tevador/50160d160d2…52ae02eb3d17024#gistcomment-4026264

To have such fine-grained view wallet types?

No, I think the comment is clear, I should have going back to look up the tiers ... my bad probably ...

I mean, only few people use accounts, how many people then will use a view-only wallet that is restricted to a single account?

It was originally meant as a feature for merchants and I thought it had no downsides, but it turned out to have downsides.

Personally I don't have a problem if those account-only view wallets turn out to be nothing mere than a fleeting dream :)

"and it would be up to the wallet how that address space is divided." -> in other words, a wallet can say "the first 1000 addresses are -> account 1, next 1000 addresses are account 2" etc. something like that but with more sensible figures? is that how accounts would be kept?

exactly

Good. I was also understanding it this way, and I became convinced today that would work out.

the main point is that the addressing scheme would become independent of how accounts are defined (and if they are defined)

right now the 64-bit address is mapped into 2 32-bit address/subaddress indices; that mapping is wallet-defined

64-bit address index*

If the reference implementation goes ahead and proposes something sensible that people then follow, except if they have good reasons not to

No need to hard-code this so deep, even into the blockchain like today

I follow, I like

OK. So I will update the proposal not to assume any particular structure for the address index. 56-bit indexes also seems sensible to me

no objections from me

is there a consensus about the 8-byte encrypted address tag? do we need more feedback (not many attendees today)?

Hard to say, with the gaps in my understanding I detected today ...

A bit out my league :)

I like em

Well, maybe there are not strong negative feelings. tevador if you are on-board and willing, it might be fine to add the 8-byte tags to jamtis. The final iteration of jamtis will require and get a lot more scrutiny.

We are past the hour now, so I will call the meeting here. Thanks for attending everyone.

Are we getting closer to a "menu" that would be understandable for merchants, exchanges, wallet developers, and users?

Very interesting today, thanks

I think we are converging on a proposal that might be close to final

Just give me some time to update the gist

Yeah the only open question in my mind is exact semantics for the reference implementation of accounts/addresses.

After consulting a thesaurus... 'address category' is probably the best alternative (just 'category' on the user-facing side) :)

I want to capture that an 'account' doesn't have any strict significance. They are more like collections/groups of addresses for organizing your balance...

<UkoeHB> "I want to capture that an '..." <- Why not use the terms "collection" or "groups" then? IMO if you are using common words (of similar length) to define another word, just use the words from your definition instead.

From a UX perspective, I'm fine with doing away with the entire concept of accounts. They were confusing to me when getting started because I expected them to DO something (like, require separate passwords or something). Simply generating new subaddresses without any grouping is enough in my opinion.

In most use cases where you want a separation of funds or grouping of addresses, you're really better off with a separate wallet with its own unique seed and private keys anyway.

wernervasquez[m]: lol maybe you're right

Aren't they useful for comingling funds but tracking them separately? I wonder how many people actually use that functionality? Perhaps husband and wife joint wallet with separate accounts in case someone dies they can access either.

if anyone has contacts at kraken we should just ask them what they want :)

or alex local monero guy