huzzah!

gingeropolous: electrum is nice. But it seems to me that the good way to use it is to run your own bitcoin node, your own electrumx server that talks to ONLY that bitcoin node, and run your own electrum wallet that talks to ONLY that electrumx server ...

Which puts it out of reach for most people

OK, so about the linkable anonymity model in CLSAG

Right now the current version reduces a linkable anonymity adversary to one that breaks a game relating public keys to key images

but the way the wrapped algorithm currently breaks that game doesn't map the linkable anonymity player's result to its own result the way we thought it did

So my idea is to revert from that linking-tag-type game to a DDH variant that _also_ passes along certain random oracle queries along with it

This has the added benefit of letting the wrapped algorithm better simulate signing oracle queries, since it can make up its own secret auxiliary keys but use the signing keys provided by the DDH challenger

And I have a new way for the DDH player to properly interpret the linkable anonymity player's result and map it to a DDH result in a way that breaks it with non-negligible advantage!

This wrapping algorithm is more subtle than I had previously thought, but it works on paper now

A previous anonymity definition didn't work as nicely with this DDH hardness assumption because of how the oracle queries had to work... but with the linkable anonymity definition it works very nicely

The basic idea is that the player requests certain signatures, and receives either the signature it requested, or a "flipped" version using another key

and the player needs to figure out which one it received

And the trick is to map oracle queries properly, as well as interpret the result this player provides to its challenger (the challenger is also the DDH player in this wrapped algorithm)

What a world

It's a neat reminder of how wild the idea of wrapping algorithms is... you suppose that some algorithm can break your new construction, and "trick" the algorithm into solving a presumably-impossible known problem; and then conclude this is absurd, so such an algorithm can't exist!

The way I'm having this modified DDH player (== anonymity challenger) operate is to internally decide if it's going to "flip" the signatures or not

If it gets random DDH points, then whether it flips or not, the anonymity player cannot have an advantage in the game

If it gets structured DDH points (relating to key images), then because the signing oracle queries verify/link as expected, the anonymity player has an advantage, and its response can be interpreted by the challenger since the challenger knows if it flipped signatures or not

And then this anonymity advantage is passed up to the DDH challenger

The advantage isn't identical between the two games, but it's non-negligible in both cases... and that's the important part

Meaning a non-negligibly-successful anonymity player can be wrapped to build a non-negligibly-successful DDH player

and that's the contradiction (if this DDH variant is assumed to be difficult)

I'm still debating whether or not it's necessary to give the DDH player access to the random oracle... I think it is necessary because of the case where the anonymity challenger provides its own keys for use in signature oracle anonymity sets

but I don't think this is problematic for the DDH game

Similar to how the use of a hash function (modeled as a random oracle) to build public Pedersen generators doesn't provide any advantage to an adversary (and is necessary for NUMS)

I wish I could help you but I can't help with this haha

Heh, just providing an update

It's a lot of scribbling in notebooks and getting frustrated at subtle things :/

When it comes to security models and proofs, there's not much to show for it until everything is all worked out