21:35:09 <tevador> https://github.com/monero-project/research-lab/issues/92#issuecomment-985018982
21:52:33 <UkoeHB> thanks tevador, btw it seems a wallet would have to store exponentially more subaddress keys in the lookup table: num_subaddr*num_default_paymentrequests
21:52:53 <UkoeHB> err I guess that's multiplicative
21:53:41 <sethsimmons> <tevador> "https://github.com/monero-..." <- This is... Fascinating and worth getting a lot of feedback on.
21:53:41 <sethsimmons> How does it compare to LNURL/BOLT11 and other LN payment request approaches? I'm not very familiar with them but curious if a similar approach has been explored before.
22:03:12 <UkoeHB> tevador: is the goal here to move the 'payment ID' behavior into an implicit account-side index?
22:05:02 <merope> If we remove the concept of addresses entirely, then what's the point of having accounts *and* subaddresses? Why not have "only" accounts, and generate a new one for each person/entity we're interacting with?
22:05:52 <merope> That would simplify the UX a lot, imo
22:06:17 <UkoeHB> Also, I'm pretty sure this is like Janus A but with an additional tier (~ tier 0 I guess). It would be like Janus D if you set `k^vs = k^vr`. 
22:06:59 <UkoeHB> merope: in this case, account = subaddress and payment request = sub-subaddress
22:13:56 <merope> hmm, so the wallet would show a "1-dimensional" list of accounts, each with their own transaction history? (as opposed to the current "2-dimensional" setup of accounts, each with their own subaddresses, each with their own transaction list)
22:15:02 <UkoeHB> yes I think so, since right now 'accounts' are just ranges of subaddresses
22:15:18 <UkoeHB> instead they would be ranges of sub-subaddresses
22:18:12 <UkoeHB> I'm guessing large-volume users would have to adopt conventions around payment-request indices. I.e. re-use a payment-request for the same purpose... Otherwise the subaddress table would become unmanageable.
22:20:56 <merope> That sounds like a clusterfuck waiting to explode... I guess creating one subaddress range per user would slow things down too much?
22:22:53 <merope> Another question: the output construction requires the generation of a random scalar t. What happens if the same scalar t is [accidentally/voluntarily/maliciously] reused?
22:35:08 <tevador> UkoeHB: why would there be more keys in the lookup table? It should be the same as if a new subaddress is used for each payment.
22:35:31 <tevador> UkoeHB: you might be right about the Janus A/D classification
22:48:34 <UkoeHB> it seems like people would be generating a lot more payment requests than new subaddresses
23:00:31 <tevador> It depends on the usage. A payment request is also reusable if all payments to it have the same purpose (for example, a donation).
23:16:27 <UkoeHB> yeah I think it would be manageable if UX is implemented effectively