One thing we could do is record if an output is change/self-spend in the address id (e.g. if the first 4 bytes are 0, then the 5th byte records change/self-spend). This would let k^i_a accounts see change/self-spends. Or, we could let change/self-spends only be deducible from address ids by the ViewAll wallet. However, if a ViewAll is customer to a ViewReceived* wallet for obtaining received outputs, then it is probably

more efficient to do key-image-based lookups for identifying change/self-spends (more efficient than re-doing ciphering on all view tag matches).

This might be my compiler over-optimizing my test, but I get ~80ms to do 1mill decryptions of an 8-byte uint with blowfish, and initializing the blowfish context is only 40us.

here is the test code: github.com/UkoeHB/monero/blob/serap…/tests/performance_tests/blowfish.h

I was just wondering, how is OSPEAD going?

<asd_> "I was just wondering, how is..." <- I am concentrating on BCH stuff for the next week or two. I have a draft of part of OSPEAD if you want to see it.

tevador I am writing a summary of output->address mapping approaches

thoughts?

Is there a use-case where segmenting the account space would be useful? account groups? I feel like only very large organizations could use it, and even then putting all funds on one single master key is risky.

Is there a use case for 4.3 billion different accounts? What was the rationale when the 64-bit space was divided like this?

Also, I think the mapping `i -> {branch, accnt}` would be backward incompatible if anyone currently has an account `i >= 2^16`.

I agree 4.3bill accounts isn't very useful, but it doesn't add complexity (just unused bits).

or keep calling it `i` and just use the first 16 bits to look up the correct key

The rationale was probably `uint32_t` and `uint64_t` are standard sizes.

you could have a uint16_t account and uint64_t address index (48 bits used), together packed into 64 bits

What would be the advantage to encrypting `{i,j}` with `k^i_a`? Wouldn't the `i` component just end up acting as an additional MAC (i.e. expected constant)?

the `i` would be the MAC

oh, in that case it isn't needed: just use padding bits

it would be needed for change, where you'd encrypt with k_vb and not know the `i` implicitly

so it's easier to always encrypt (i,j)

ohh right I forgot that detail; if you don't rely on a lookup table, then change outs also need to learn the `i,j`

ok I am warming up to a 16/48 bit indexing scheme

unfortunately that would not be backwards compatible

right

we could specify that every 2^16 accounts share the same private key, that would be equivalent to my divisions idea, but without calling it a division...

anyways it's up to the wallet how the 64-bit space is presented to the user

there could be wallets that don't use the 32/32 split

Suppose you have an account `i >= 2^16`. A) disallow creating jamtis addresses for those accounts (users, if any actually exist, would have to send funds to a new account). B) expand the address space to 60 bits (32|48), if receiving to a legacy account then just match the first 16 bits of the account index as MAC before checking the nominal spend key (for change/self-spends you would check nominal spend key for all

accounts that match the account key).

"accounts that match the account key" -> account index

you mean 80 bits?

ah

I'm not sure if there are any 80-bit block ciphers

no, only 80 bits in the address extenders; the block cipher would remain 64 bits (16 | 48)

A seems like a much cleaner solution. I wonder how many actual users would be affected. Can't be many

Since you need `k^i_a` anyway to check account tags, it is fine to just match 16 bits against `i` after decrypting.

Yeah A would be easier to implement: "error!"

I don't think there would be an error. Accounts >65K could still be displayed in the wallet, the would just not have any address to send to.

change outputs would end up going to an unexpected place

so maybe only self-spends to other accounts could be permitted (simplest ux)

I do like the idea to expand the normal address space, since 8 bytes could be too small for a robust PID:address mapping.

48 bits is still too small for collision resistance (already 1% chance of collision with 2.5M addresses), so you'd still need collision detection, but then you can just use 32 bits

collision resistance in what context?

monero-project/research-lab #94 are return addresses no longer in the radar for MRL?

It's kind of out-of-scope for MRL. Aren't return addresses just a memo thing?

UkoeHB: I meant if you truncate a 64-bit PID to 48 bits, or alternatively if you generate random 48-bit indices per user

summary about output->address mapping approaches (reading material for meeting tomorrow): gist.github.com/tevador/50160d160d2…52ae02eb3d17024#gistcomment-4025357