12:17:16 <derbleak> https://eprint.iacr.org/2020/454.pdf
12:37:21 <UkoeHB_> 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 <UkoeHB_> 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 <UkoeHB_> No additional storage required ^.^
12:48:38 <knaccc> 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 <knaccc> I'm not exactly sure what you're suggesting
12:50:51 <UkoeHB_> Right, add a condition where change outs for 2-out tx use a different XOR value, i.e. the change tag
12:51:33 <UkoeHB_> Which is also deterministic from tx data and the view key
12:52:53 <knaccc> 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 <UkoeHB_> The change tag isn't stored, just computed locally
12:53:41 <knaccc> actually i can't even remember what a change tag is :) what is that?
12:54:04 <knaccc> how is it computed locally?
12:55:00 <UkoeHB_> 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 <UkoeHB_> change tag = H("change_tag", private view key, tx data)
12:55:55 <knaccc> thanks yeah i'm rebooting my brain and looking at #6456
12:56:31 <UkoeHB_> 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 <knaccc> i think what you're describing sounds like total genius :)
12:59:09 <knaccc> i do also like your other comment about choosing the change output commitment blinding factor differently
12:59:23 <knaccc> that sounds good too
12:59:47 <UkoeHB_> My comment was to not change it lol
12:59:51 <knaccc> i know
12:59:56 <knaccc> i'm saying i like it nonetheless :)
13:00:47 <knaccc> it actually sounds cleaner to me
13:00:54 <UkoeHB_> Cleaner?
13:02:24 <knaccc> 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 <UkoeHB_> I'm not too hung up on which one to go with. Depends on the easiest to implement imo
13:03:32 <knaccc> the latter would require all wallets to decrypt amounts differently after a certain block height, right?
13:04:01 <knaccc> 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 <UkoeHB_> Output commitment blinding factors are no longer stored in tx data ^.^
13:05:17 <knaccc> 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 <UkoeHB_> Yeah
13:05:45 <UkoeHB_> But also, I'm not sure I understand your point
13:05:49 <knaccc> i like the idea that wallets could start using the former method right now
13:05:57 <UkoeHB_> How though?
13:06:09 <UkoeHB_> Commitment blinding factors are also deterministic
13:06:50 <UkoeHB_> Since RCTTypeBulletproof2 went out
13:07:25 <knaccc> 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 <UkoeHB_> Sure, the same is true for encrypted amounts. They would still be incompatible with other wallets
13:07:53 <knaccc> and then when you check the ecdhinfo encrypted blinding factor, you'll test whether which type of deterministic creation was used
13:08:52 <UkoeHB_> I'm saying there is no encrypted blinding factor any more
13:08:58 <UkoeHB_> It's computed locally now
13:09:09 <UkoeHB_> Miss that update?
13:09:41 <knaccc> 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 <knaccc> omg
13:10:02 <knaccc> ok my memory is so bad
13:10:10 <UkoeHB_> It's deterministic :) see ZtM section 5.something
13:10:13 <knaccc> ok ok i know what you're talking about
13:10:26 <knaccc> it's embarassing, because i was the one that suggested that change :)
13:10:32 <UkoeHB_> Lmao
13:10:33 <knaccc> i just forgot about that part :)
13:12:30 <knaccc> i think i agree with you then about using the latter method
13:12:39 <knaccc> very very good idea, nice work
13:21:20 <UkoeHB_> great :)
13:31:00 <UkoeHB_> should I retain the 'change address' idea as an alternative on the proposal?
13:32:59 <knaccc> 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 <UkoeHB_> ok!
13:34:41 <UkoeHB_> wait are you saying I should keep it, or deprecate it?
13:35:10 <knaccc> i mean delete it out of the main post so people don't have to read through the entire journey
13:35:48 <knaccc> the change history on that is still publicly visible if people really want to go back to it
13:36:13 <knaccc> no pun intended :)
13:37:21 <knaccc> thanks so much for writing all this up
13:38:05 <UkoeHB_> got it
14:09:28 <UkoeHB_> proposal updated https://github.com/monero-project/monero/issues/6456
17:21:17 <sarang> Hello all
17:21:37 <sarang> Working on an update for 3-CLSAG, to get updated timing data for the timelock project
17:42:11 <UkoeHB_> sarang in case you missed it: derbleak posted https://eprint.iacr.org/2020/454.pdf
17:43:17 <sarang> Yep, I read it when it first appeared on IACR
23:50:41 <knaccc> 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 <derbleak> +1 ^