12:17:16 https://eprint.iacr.org/2020/454.pdf 12:37:21 knaccc what if we alter the blinding factor for the encrypted amount and use that to indicate change/not change? I mean, use the change tag to be the amount's blinding factor directly, then when reading a tx add a bit of logic to test the stored commitment with the decrypted amount (decrypted normally), and if it fails try again by decrypting with change tag (which pops a flag 'this is a change output') 12:38:40 I say blinding factor for encrypted amount instead of commitment's blinding factor, since that is likely to require a lot less development effort (recomputing the commitment happens for tx construction) 12:39:06 No additional storage required ^.^ 12:48:38 blinding factor for encrypted amount < are you referring to the ecdhinfo encrypted amount? That's now deterministic and based on the shared secret 12:48:44 I'm not exactly sure what you're suggesting 12:50:51 Right, add a condition where change outs for 2-out tx use a different XOR value, i.e. the change tag 12:51:33 Which is also deterministic from tx data and the view key 12:52:53 i'm still not getting it. that means you have to add a change tag, right? so how does that coexist with the statement "No additional storage required" 12:53:19 The change tag isn't stored, just computed locally 12:53:41 actually i can't even remember what a change tag is :) what is that? 12:54:04 how is it computed locally? 12:55:00 a) decrypt amount normally b) test output commitment with that amount c) equality failure? d) decrypt amount with change tag e) test output commitment with new amount f) equality? then it's a change output 12:55:25 change tag = H("change_tag", private view key, tx data) 12:55:55 thanks yeah i'm rebooting my brain and looking at #6456 12:56:31 Originally the change tag idea was to recompute the change tag and compare with what's stored in tx data. This way it doesn't need to be stored explicitly, just weave it into the encrypted amount 12:57:31 i think what you're describing sounds like total genius :) 12:59:09 i do also like your other comment about choosing the change output commitment blinding factor differently 12:59:23 that sounds good too 12:59:47 My comment was to not change it lol 12:59:51 i know 12:59:56 i'm saying i like it nonetheless :) 13:00:47 it actually sounds cleaner to me 13:00:54 Cleaner? 13:02:24 yeah, it just feels cleaner to do a check to see if a particular output's commitment blinding factor was determistically created in a way such that only you could have created it, rather than decrypting the ecdh amount in two different ways 13:03:32 I'm not too hung up on which one to go with. Depends on the easiest to implement imo 13:03:32 the latter would require all wallets to decrypt amounts differently after a certain block height, right? 13:04:01 whereas the former could just be done right now, and it doesn't matter if some wallets did it and others didn't 13:04:32 Output commitment blinding factors are no longer stored in tx data ^.^ 13:05:17 oh you're saying that since this would be part of the new tx format, that would be the block height change 13:05:35 Yeah 13:05:45 But also, I'm not sure I understand your point 13:05:49 i like the idea that wallets could start using the former method right now 13:05:57 How though? 13:06:09 Commitment blinding factors are also deterministic 13:06:50 Since RCTTypeBulletproof2 went out 13:07:25 right, but there is nothing stopping someone from changing a wallet to make the change output commitment blinding factor be deterministically created in a different way that incorporated the private view key 13:07:49 Sure, the same is true for encrypted amounts. They would still be incompatible with other wallets 13:07:53 and then when you check the ecdhinfo encrypted blinding factor, you'll test whether which type of deterministic creation was used 13:08:52 I'm saying there is no encrypted blinding factor any more 13:08:58 It's computed locally now 13:09:09 Miss that update? 13:09:41 i must have missed it! so then how is the recipient of the transaction supposed to know the blinding factor of the output they've received? 13:09:57 omg 13:10:02 ok my memory is so bad 13:10:10 It's deterministic :) see ZtM section 5.something 13:10:13 ok ok i know what you're talking about 13:10:26 it's embarassing, because i was the one that suggested that change :) 13:10:32 Lmao 13:10:33 i just forgot about that part :) 13:12:30 i think i agree with you then about using the latter method 13:12:39 very very good idea, nice work 13:21:20 great :) 13:31:00 should I retain the 'change address' idea as an alternative on the proposal? 13:32:59 if you're happy to deprecate it in favor of your new idea, yes i think that would help people digest the thread 13:33:47 ok! 13:34:41 wait are you saying I should keep it, or deprecate it? 13:35:10 i mean delete it out of the main post so people don't have to read through the entire journey 13:35:48 the change history on that is still publicly visible if people really want to go back to it 13:36:13 no pun intended :) 13:37:21 thanks so much for writing all this up 13:38:05 got it 14:09:28 proposal updated https://github.com/monero-project/monero/issues/6456 17:21:17 Hello all 17:21:37 Working on an update for 3-CLSAG, to get updated timing data for the timelock project 17:42:11 sarang in case you missed it: derbleak posted https://eprint.iacr.org/2020/454.pdf 17:43:17 Yep, I read it when it first appeared on IACR 23:50:41 random thought: make real index positions deterministic. do real_index_seed = H("real_index_seed" || private view key || {lexicographically sorted key images}), and then for m rings each of size n, set x = real_index_seed, then repeatedly do real_index_m = x mod n, x=(x-(x mod n))/n 23:58:48 +1 ^