10:55:46 <m-relay> <c​haser: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>
10:55:48 <m-relay> <c​haser: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.
11:03:13 <m-relay> <c​haser: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>
11:03:14 <m-relay> <c​haser:monero.social> otherwise a future QC will be able to retrieve everything anyway.)
11:51:33 <m-relay> <r​ottenwheel:unredacted.org> Bulletproofs & Range Proof in Monero using Bulletproofs - 
11:51:34 <m-relay> <r​ottenwheel:unredacted.org> https://risencrypto.github.io/Bulletproofs/