<c​haser:monero.social> some Carrot questions:

<c​haser:monero.social> 1] for Carrot wallets under FCMP++, won't there still be a use case for disposable wallets for forward secrecy -- namely, to altogether prevent the leakage of `k_v` (incoming view key) (conditional on not leaking any address ever)? wouldn't that prevent a quantum adversary from being able to tell if two enotes were (ultimately) received to the same wallet?

<c​haser:monero.social> 2] what is an "external self-send enote"?

<c​haser:monero.social> 3] what is "external change"?

<j​effro256:monero.social> 1] Yes the way I initially worded that was not clear, sorry. In the original comment, I was saying that you don't need a disposable wallet for *internal* self-sends in case that your private view-incoming key got leaked. But for high-privacy users who can't take any chances, there will still be benefit for creating a new view-incoming key for every individual receive address they <clipped messag

<j​effro256:monero.social> give out. So that if any of the public addresses got leaked to a quantum computer, the damage would be contained to received enotes for that specific subaddress only. There might be a wallet out there at some point that consolidates all your individual private view-incoming keys into one "wallet" for better UI. Until that time, one can create N wallets for N receive addresses

<j​effro256:monero.social> 2] The difference between *internal* and *external* is that *internal* uses a symmetric key for encrypting sends, whereas *external* uses a ECDH exchange with one's view-incoming key. A self-send enote is any one that you make back to yourself. So an external self-send enote is one that you send back to yourself and encrypt with a ECDH against your view-incoming key. This is how s<clipped messag

<j​effro256:monero.social> elf-sends work today: we basically treat our self-send address like any other (with come caveats), do the ECDH, and construct change enotes. This isn't quantum forward secrect, however. For quantum forward secrecy, we want an *internal* enote. However, sometimes that isn't possible, as with legacy wallets

<j​effro256:monero.social> 3] External change is an external self-send enote whose `enote_type` is equal to `"change"`, as opposed to `"payment"`