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')

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)

No additional storage required ^.^

blinding factor for encrypted amount < are you referring to the ecdhinfo encrypted amount? That's now deterministic and based on the shared secret

I'm not exactly sure what you're suggesting

Right, add a condition where change outs for 2-out tx use a different XOR value, i.e. the change tag

Which is also deterministic from tx data and the view key

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"

The change tag isn't stored, just computed locally

actually i can't even remember what a change tag is :) what is that?

how is it computed locally?

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

change tag = H("change_tag", private view key, tx data)

thanks yeah i'm rebooting my brain and looking at #6456

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

i think what you're describing sounds like total genius :)

i do also like your other comment about choosing the change output commitment blinding factor differently

that sounds good too

My comment was to not change it lol

i know

i'm saying i like it nonetheless :)

it actually sounds cleaner to me

Cleaner?

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

I'm not too hung up on which one to go with. Depends on the easiest to implement imo

the latter would require all wallets to decrypt amounts differently after a certain block height, right?

whereas the former could just be done right now, and it doesn't matter if some wallets did it and others didn't

Output commitment blinding factors are no longer stored in tx data ^.^

oh you're saying that since this would be part of the new tx format, that would be the block height change

Yeah

But also, I'm not sure I understand your point

i like the idea that wallets could start using the former method right now

How though?

Commitment blinding factors are also deterministic

Since RCTTypeBulletproof2 went out

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

Sure, the same is true for encrypted amounts. They would still be incompatible with other wallets

and then when you check the ecdhinfo encrypted blinding factor, you'll test whether which type of deterministic creation was used

I'm saying there is no encrypted blinding factor any more

It's computed locally now

Miss that update?

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?

omg

ok my memory is so bad

It's deterministic :) see ZtM section 5.something

ok ok i know what you're talking about

it's embarassing, because i was the one that suggested that change :)

Lmao

i just forgot about that part :)

i think i agree with you then about using the latter method

very very good idea, nice work

great :)

should I retain the 'change address' idea as an alternative on the proposal?

if you're happy to deprecate it in favor of your new idea, yes i think that would help people digest the thread

ok!

wait are you saying I should keep it, or deprecate it?

i mean delete it out of the main post so people don't have to read through the entire journey

the change history on that is still publicly visible if people really want to go back to it

no pun intended :)

thanks so much for writing all this up

got it

proposal updated monero-project/monero #6456

Hello all

Working on an update for 3-CLSAG, to get updated timing data for the timelock project

sarang in case you missed it: derbleak posted eprint.iacr.org/2020/454.pdf

Yep, I read it when it first appeared on IACR

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

+1 ^