Anyone want to play Moneroversary games

sarang suraeNoether Isthmus knaccc? :D

?

We're looking for people to play Moneroversary games (see -community)

Thought I'd query the MRL

The ivory tower looks awfully boring

knaccc about the real_index_tag idea for inputs: unfortunately someone with the view key could fool you into believing one of your outputs has been spent; that problem is what killed my original idea for the same effect

yeah the real_index_tag is far from a perfect solution since it can't tell you if you've had funds stolen (if the thief is smart enough to fork the wallet and mangle the real_index_tag). i do still think it has utility, but it's imperfect enough that i wouldn't waste any effort defending it

i see it as a very cheap way of getting extra functionality. on a 2-in 2-out tx, the cost would only be 1 byte

Even beyond a thief, if someone gets your view key they can fool you into thinking your outputs have been spent

So... you could fool a thief into thinking your outputs have already been spent ?

people other than thieves might have your view key ^.^

the way i see it, we already have to warn people anyway when they create a view-only wallet that they cannot trust the balance. so if we're having to warn them anyway, why not at least try to make the balance appear more sensibly

well there is a more reliable way, generating fake responses deterministically based on your view key, which reveals the true index

That of course requires all your wallets to do this

But does work very simply

what is "generating fake responses deterministically based on your view key"?

You can use a hash input seed value in MLSAG/CLSAG signatures to later recover the signing index: github.com/SarangNoether/skunkworks/blob/clsag/clsag/clsag.py#L62

You can't trick it into thinking a different index is the real signer, but it only works for identifying spends reliably if all your wallets generate scalars this way

(in that code example, the seed is whatever you choose to provide)

oh very cool

You could do a similar thing in Triptych, or could use the seed approach to store up to 64 bytes of arbitrary hidden data

These approaches are neat because they don't imply any extra overhead on the network

only on clients that choose to parse for the data

The MLSAG/CLSAG approach does require to test up to `N-1` hash-to-scalar operations

In Triptych you can avoid this by storing the index as a hidden value and setting the index matrix mask to a deterministic pseudorandom value for testing

So you'd recover the index via a single hash operation (and some easy scalar operations), and then test the matrix commitment