00:14:30 On July 1st we are forking monero to exclude ciphertrace. This is fair notice. 15:48:29 MRL meeting agenda for Wednesday: https://github.com/monero-project/meta/issues/1395 17:02:46 hm... we should be able to get the 2.3.1 Address generator tier(jamtis draft) for monero-PSK as well. we can do the kdf twice in a row. so you would only need to share the secret after the first and the merchant address generator tier can use it to derive the PSK's. the caveat compared to the jamtis adress generator would be t [... too long, see https://mrelay.p2pool.observer/e/jsrWzIYLcmxQSURO ] 17:03:26 this also means the address generator knows just a very tiny subset of information about the wallet (just if the addresses generated with it where actually used or not). it is not like a view key and there can be multiple 18:39:55 tevador: I think the downsides of the filter-assist tier are worth documenting in the Jamtis spec as well (if the address is known, filter-assist tier can determine enotes received to that address, and if >1 enotes received to the address can determine all enotes received to that address) 19:04:12 spirobel: Monero-PSK draft has AddrGen tier: https://gist.github.com/tevador/9169235b3c0c97e735f58a8c2ba92502#36-account-access-tiers 19:06:22 jberman: 1. Jamtis filter-assist cannot link enotes to known addresses. 2. Jamtis filter-assist cannot know if the same address received >1 enote. These weaknesses were in Jamtis-Seraphis, but Jamtis-PQ solves them with the added d_ir key, which is unknown to filter-assist. 19:18:44 the AddrGen onchain capabilities are mentioned as "locate received payments". they are only able to locate the first payment for the addresses that where generated with this specific key 19:19:50 No, they can detect all payments. 19:22:08 At least in my draft, no blockchain data at all are required when enumerating lookup tags. See section 5.8. If you know s_ga^i, you can just loop through all possible values of j and n until you locate all payments. 19:22:52 The lookup tag is calculated as H_16("Monero-PSK lookup tag" || s_psk^(i,j) || n) 19:25:37 Well that's awesome news, nice. Those were major limitations of the tier > jberman: 1. Jamtis filter-assist cannot link enotes to known addresses. 2. Jamtis filter-assist cannot know if the same address received >1 enote. These weaknesses were in Jamtis-Seraphis, but Jamtis-PQ solves them with the added d_ir key, which is unknown to filter-assist. 19:28:41 IIRC the reason that key wasn't added prior was because of the hesitation on larger address sizes. With the addition of PQ protection, seems the additional key has a more marginal impact on address sizes now 19:30:29 tevador: yes this is not necessarily so. 19:31:11 it is better to rewrite it so the addrgen tier can only locate the first payments for the addresses it generated 19:41:39 Be more specific. Link a chapter and the changes that need to be made. 20:10:29 should be section 5.4 dont see why after the first transaction it should necessarily be possible for the recipient to get the shared secret from the psk for the following txs. some nits : i wouldnt use the two indices ... in practice just one index is enough. this major minor subaddress index stuff ... not sure if an account i [... too long, see https://mrelay.p2pool.observer/e/9o6G0oYLaThlVktP ] 20:18:32 OK, section 5.4 and the change you are proposing? 20:40:09 the way this draft works currently is that it is possible to enumerate all the lookup tags without blockchain data. 1. the question is if we can reduce that so the addrgen tier keys can only locate the first tags of the addresses they generated. Without introducing the need to access blockchain data. 2. the question is if that [... too long, see https://mrelay.p2pool.observer/e/yaH00oYLRjE1bkZ3 ] 20:52:27 My solution with the counter actually avoids the footgun. Anyone who knows the address is able to construct the correct lookup tag. They can just select the lowest n that produces a unique tag. This will work correctly even after Bob restores his wallet from the seed and "forgets" how many transactions he has sent to Alice.