01:18:40 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 01:18:40 more efficient to do key-image-based lookups for identifying change/self-spends (more efficient than re-doing ciphering on all view tag matches). 02:50:58 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. 02:52:58 here is the test code: https://github.com/UkoeHB/monero/blob/seraphis_lib/tests/performance_tests/blowfish.h 09:04:17 I was just wondering, how is OSPEAD going? 18:00:26 "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. 18:22:32 tevador I am writing a summary of output->address mapping approaches 18:40:40 https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#gistcomment-4025175 18:40:42 thoughts? 18:47:49 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. 18:49:31 Is there a use case for 4.3 billion different accounts? What was the rationale when the 64-bit space was divided like this? 18:50:10 Also, I think the mapping `i -> {branch, accnt}` would be backward incompatible if anyone currently has an account `i >= 2^16`. 18:50:50 I agree 4.3bill accounts isn't very useful, but it doesn't add complexity (just unused bits). 18:51:06 or keep calling it `i` and just use the first 16 bits to look up the correct key 18:51:30 The rationale was probably `uint32_t` and `uint64_t` are standard sizes. 18:52:53 you could have a uint16_t account and uint64_t address index (48 bits used), together packed into 64 bits 18:53:53 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)? 18:55:11 the `i` would be the MAC 18:56:32 oh, in that case it isn't needed: just use padding bits 18:57:50 it would be needed for change, where you'd encrypt with k_vb and not know the `i` implicitly 18:58:16 so it's easier to always encrypt (i,j) 18:59:24 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` 19:01:38 ok I am warming up to a 16/48 bit indexing scheme 19:02:13 unfortunately that would not be backwards compatible 19:02:17 right 19:05:45 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... 19:06:54 anyways it's up to the wallet how the 64-bit space is presented to the user 19:07:15 there could be wallets that don't use the 32/32 split 19:10:34 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 19:10:34 accounts that match the account key). 19:11:19 "accounts that match the account key" -> account index 19:12:04 you mean 80 bits? 19:12:10 ah 19:12:27 I'm not sure if there are any 80-bit block ciphers 19:12:59 no, only 80 bits in the address extenders; the block cipher would remain 64 bits (16 | 48) 19:14:29 A seems like a much cleaner solution. I wonder how many actual users would be affected. Can't be many 19:14:30 Since you need `k^i_a` anyway to check account tags, it is fine to just match 16 bits against `i` after decrypting. 19:16:23 Yeah A would be easier to implement: "error!" 19:17:45 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. 19:18:48 change outputs would end up going to an unexpected place 19:19:33 so maybe only self-spends to other accounts could be permitted (simplest ux) 19:23:12 I do like the idea to expand the normal address space, since 8 bytes could be too small for a robust PID:address mapping. 19:28:58 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 19:33:52 collision resistance in what context? 20:50:29 https://github.com/monero-project/research-lab/issues/94 are return addresses no longer in the radar for MRL? 20:54:56 It's kind of out-of-scope for MRL. Aren't return addresses just a memo thing? 21:02:02 UkoeHB: I meant if you truncate a 64-bit PID to 48 bits, or alternatively if you generate random 48-bit indices per user 21:07:11 summary about output->address mapping approaches (reading material for meeting tomorrow): https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#gistcomment-4025357