17:22:30 This is a great question, so I went back to look at it and I believe that it IS possible 17:23:29 There's two ways to do it, with seemingly similar properties against quantum computer privacy attacks 17:24:11 One is to straight up encode `k_v * K^change_o` and encrypt it with an XOR'ed shared secret 17:25:03 The other is to encode the point `F = y^-1 * k_v * K^change_o` where `y` is the recipient's shared secret 17:25:29 BTW `K^change_o` is the sender's onetime address in that transaction and `k_v` is the private view key 17:28:07 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 17:28:20 ... how do you know the sender's one-time key though? FCMP++ exposes O~, yet that's the re-randomized one-time key. 17:28:48 You'd need to deterministically generate re-randomization blinds, right? 17:32:10 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 17:32:11 that refund output 17:32:58 Rerandomization shouldn't matter AFAICT as long as the relationaship between the points in the subaddress is (A, k_v A) 17:33:28 And as long as the sender (refundee) can rederive the private key for A 17:34:32 BTW carrot also cures cancer I forgot to mention 17:37:35 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. 17:40:14 Well an even more trivial method for refund address exists: encrypt the full change address to them 17:40:26 But that costs 64 bytes instead of 32 17:41:49 What's the benefit of having return addresses? I don't get it 17:43:40 UX, really 17:44:03 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. 17:45:43 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 17:47:23 Ostensibly you wouldn't include a refund address in a transaction where you don't expect refunds 17:49:56 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" 17:49:57 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 17:51:08 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 17:52:05 It would only add 32 17:52:05 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 17:53:16 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 :) 17:55:44 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 17:56:20 Also true 17:56:44 I just worry that this will be the next unlock_time 17:57:11 IIRC, pruned transactions are actually shrinking slightly under FCMP++ since there aren't any decoy member key offsets anymore 17:59:01 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 18:00:14 If you ask me, Monero's complexity is already now beyond "bad". I think we should be very careful with introducing new stuff. 19:31:32 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 19:33:34 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) 19:34:36 could generate a new return address each time 19:37:16 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 20:03:35 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 20:06:48 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... 20:15:24 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 20:16:23 External meaning asymmetric addressing methods used today 20:17:13 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 20:22:18 Just don't use refund addresses on-chain. Public addresses shouldn't appear in the blockchain. 20:27:51 I'm certainly inclined to agree, I just like to squeeze a topic dry to make sure I'm not missing anything 20:39:27 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 20:42:17 I’m just thinking how much slower the network would be too 21:06:25 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 21:08:03 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 21:08:51 You might also be interested in this issue: https://github.com/monero-project/research-lab/issues/106 21:09:19 Or this idea: https://github.com/monero-project/research-lab/issues/106#issuecomment-2143280582 21:09:26 Which also applies to Carrot 21:12:52 Thanks, I’ll have a gander!