thanks tevador, btw it seems a wallet would have to store exponentially more subaddress keys in the lookup table: num_subaddr*num_default_paymentrequests

err I guess that's multiplicative

<tevador> "github.com/monero-..." <- This is... Fascinating and worth getting a lot of feedback on.

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.

tevador: is the goal here to move the 'payment ID' behavior into an implicit account-side index?

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?

That would simplify the UX a lot, imo

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`.

merope: in this case, account = subaddress and payment request = sub-subaddress

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)

yes I think so, since right now 'accounts' are just ranges of subaddresses

instead they would be ranges of sub-subaddresses

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.

That sounds like a clusterfuck waiting to explode... I guess creating one subaddress range per user would slow things down too much?

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?

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.

UkoeHB: you might be right about the Janus A/D classification

it seems like people would be generating a lot more payment requests than new subaddresses

It depends on the usage. A payment request is also reusable if all payments to it have the same purpose (for example, a donation).

yeah I think it would be manageable if UX is implemented effectively