-
m-relay<chaser:monero.social> got it, thank you. such a wallet is an interesting idea. a different hierarchy could deterministically generate multiple `k_v`'s. IIUC the downside would be that scanning time increases linearly with the number of `k_v`'s. however, since the intention is one-time use, a `k_v` could be "flushed" after the first received enote. this way, regular scanning isn't _O(`k_v` index)_, only<clipped message>
-
m-relay<chaser:monero.social> basically _O(unfulfilled payment requests)_. restoring from a mnemonic would take longer though, _O(`k_v` lookahead distance), and once done, you'd need to decide what to do with the `k_v`'s in the last lookahead range.
-
m-relay<chaser:monero.social> alright, so external change is a kind of an external self-send, and that's the "old" way of doing self-sends, which will still be used in legacy-mnemonic-derived wallets generated pre-fork, because there it doesn't make sense to use a symmetric key. (you either haven't and won't ever leak any address from that wallet, which will give it forward-secret self-sends post-fork anyway, <clipped message>
-
m-relay<chaser:monero.social> otherwise a future QC will be able to retrieve everything anyway.)
-
m-relay<rottenwheel:unredacted.org> Bulletproofs & Range Proof in Monero using Bulletproofs -
-
m-relay<rottenwheel:unredacted.org> risencrypto.github.io/Bulletproofs