<j​effro256:monero.social> This is a great question, so I went back to look at it and I believe that it IS possible

<j​effro256:monero.social> There's two ways to do it, with seemingly similar properties against quantum computer privacy attacks

<j​effro256:monero.social> One is to straight up encode `k_v * K^change_o` and encrypt it with an XOR'ed shared secret

<j​effro256:monero.social> The other is to encode the point `F = y^-1 * k_v * K^change_o` where `y` is the recipient's shared secret

<j​effro256:monero.social> BTW `K^change_o` is the sender's onetime address in that transaction and `k_v` is the private view key

<j​effro256:monero.social> The subaddress table would need to support refund address so it would be a map of address spend pubkeys to subaddress index PLUS an optional tx-specific shared secret where the onetime address for refund was created

<k​ayabanerve:matrix.org> ... how do you know the sender's one-time key though? FCMP++ exposes O~, yet that's the re-randomized one-time key.

<k​ayabanerve:matrix.org> You'd need to deterministically generate re-randomization blinds, right?

<j​effro256:monero.social> In a 2-out transaction, the onetime pubkey you use it simply just the *other* onetime pubkey that's not yours. This is treated as the subaddress spend pubkey. The point `k_v K^change_o` is treated as the subaddress view pubkey. Then you send normally to that recovered subaddress. The original sender (now refund recipient) needs to put that in their subaddress table when they scan <clipped message>

<j​effro256:monero.social> that refund output

<j​effro256:monero.social> Rerandomization shouldn't matter AFAICT as long as the relationaship between the points in the subaddress is (A, k_v A)

<j​effro256:monero.social> And as long as the sender (refundee) can rederive the private key for A

<j​effro256:monero.social> BTW carrot also cures cancer I forgot to mention

<k​ayabanerve:matrix.org> Ah, right. Basing it off the outputs... I really don't love that assumption. There's some schemes where sending to a change addr you don't have the view key for makes sense.

<j​effro256:monero.social> Well an even more trivial method for refund address exists: encrypt the full change address to them

<j​effro256:monero.social> But that costs 64 bytes instead of 32

<s​trawberry:monero.social> What's the benefit of having return addresses? I don't get it

<j​effro256:monero.social> UX, really

Huh? That you can return funds sent to you if for whatever reason that's the right thing to do? In a safe and reliable way. And still sender privacy is preserved.

<s​trawberry:monero.social> Safe and reliable way unless the sender deleted his wallet after, or if he sent from a swap service or exchange, many reasons why you don't want automatic refunds

<j​effro256:monero.social> Ostensibly you wouldn't include a refund address in a transaction where you don't expect refunds

Looks a bit like a fallacy to me, to put it bluntly. "It won't work each and everytime, therefore not perfect, therefore don't want"

<j​effro256:monero.social> But I definitely see the point in that careful recipients are going to double-check with the sender that the refund address is still active before sending anyways, which kind of defeats the point of an non-interactive refund

<s​trawberry:monero.social> It's more that it could cause loss of coins which otherwise could have been returned manually, and I was under the impression that this would add 64 bytes to every tx, even those which don't want or need to use a return address

<j​effro256:monero.social> It would only add 32

Yes, I think that was the main argument back then to *not* introduce them, despite having worked out everything up to the details: Use will be probably not frequent enough to burden each and every tx with the addition bytes

But hey, we will soon have transactions that are several KB again, like in the good old times of that, what was is, "Borromean" stuff, what are 32 bytes more compared with FCMP :)

<j​effro256:monero.social> Tbf, 32 bytes is non insignificant compared to just the size of a pruned transaction, which is how wallets pull txs from the daemon during scanning

Also true

<s​trawberry:monero.social> I just worry that this will be the next unlock_time

<j​effro256:monero.social> IIRC, pruned transactions are actually shrinking slightly under FCMP++ since there aren't any decoy member key offsets anymore

Well, I don't think that anybody votes for introducing them now. The subject came up in connection with a fork that implements that, and question was whether we could as well *if we wanted*, as a hypothetical scenario - a protocol question

If you ask me, Monero's complexity is already now beyond "bad". I think we should be very careful with introducing new stuff.

<o​frnxmr:monero.social> Rn each additional input costs 500 bytes. I dont think 32 bytes is that bad, i just wouldnt want to share a return address unless i opted into doing so

<o​frnxmr:monero.social> A return address would double as proof of who sent it, which could be arguably bad for receiver privacy (receiving dunda from a sanctioned address or proof that youve interacted with certain people)

<s​trawberry:monero.social> could generate a new return address each time

<o​frnxmr:monero.social> the return address would have to be "for return-only / mark as used. I wouldn't want to inadvertantly share the retuen address that my bank has with a ccs donation

<j​effro256:monero.social> Also, thinking far ahead to quantum computers unraveling transaction information, Carrot / FCMP++ is forward secret *on the condition of not knowing any of your public addresses*. Putting a return address in a transaction could expose the sender's history to quantum adversaries even if the quantum adversary only knows the *receiver's* public address

<j​effro256:monero.social> This could cause a cascading effect if a quantum adversary knows one public address, then they know that one private view key, then by scanning refund addresses, they know the private view key of the sender, and their sender, and their sender's senders, and their sender's sender's senders, so on and so forth...

<j​effro256:monero.social> Kevin Bacon's Law says that you have a good chance of unraveling all on-chain *external* transaction information knowing just one used public address using this method if everyone includes refund addresses

<j​effro256:monero.social> External meaning asymmetric addressing methods used today

<j​effro256:monero.social> Carrot, like Jamtis-RCT, has a pathway for performing *internal* transfers if you upgrade your key hierarchy such that quantum computers can't see your change outputs, even if they know your public addresses

Just don't use refund addresses on-chain. Public addresses shouldn't appear in the blockchain.

<j​effro256:monero.social> I'm certainly inclined to agree, I just like to squeeze a topic dry to make sure I'm not missing anything

<k​ewbit:matrix.org> Replace or augment the existing ring signatures with a quantum resistant hash-based signature like WOTS. Perhaps in a hybrid approach where both traditional and quantum-resistant signatures are used during a transition period. RingCT protocol could potentially be adapted crypto method like lattice-based cryptography. Seems optimistic tho

<k​ewbit:matrix.org> I’m just thinking how much slower the network would be too

<j​effro256:monero.social> Well FCMP++ is already forward secret against quantum computers, it's just EC PKE public addresses which ruin everything. If all you desire is unconditional privacy, what you could do is use lattice-based KEM *addresses* off-chain and keep FCMP++ as-is

<j​effro256:monero.social> You would need a KEM message on chain which is pretty heavy, but it shouldn't have an effect on validators, and if the math or impl is screwy then economic integrity isn't harmed

<j​effro256:monero.social> You might also be interested in this issue: monero-project/research-lab #106

<j​effro256:monero.social> Or this idea: monero-project/research-lab #106#issuecomment-2143280582

<j​effro256:monero.social> Which also applies to Carrot

<k​ewbit:matrix.org> Thanks, I’ll have a gander!