16:24:08 Hello all 16:24:38 A draft of the Triptych preprint is complete! It's awaiting initial review from suraeNoether, and then off to the IACR preprint archive for broader review 16:25:36 Based on other discussions with suraeNoether about the CLSAG security model, we'll likely continue with its modifications in a way slightly different from the Backes et al. paper, to accommodate the inability to use a corruption oracle in the same way with DDH triples 16:25:41 Such is life 16:36:10 The definition that I think will work has the challenger supply a set of (DDH-supplied) keys to the player, has the player choose two such keys as "target keys", has the player supply the rest of the ring with arbitrary keys that could be maliciously generated, and continue from there 16:36:42 So it effectively replaces the corruption oracle (which doesn't work with the DDH setup) with the player's ability to include keys of its own construction 16:58:03 suraeNoether: in the updated definition, it seems the signing oracle also needs to be effectively removed 16:58:47 Previously, the LA player could query it on a non-target key in the ring 16:59:56 But if the challenger's key set is only DDH triples, do we want to remove this capability from the oracle, or just have the oracle proceed by backpatching? 17:00:20 So maybe "needs to be removed" should be replaced by "could be removed, depending on the model we wish to capture" 19:03:45 brief update on linkable anonymity 19:04:24 the Backes definition models the adversary's ability to corrupt keys, which models an adversary like a custodial exchange or an entity capable of persuading users to hand over their private keys. This is a very strong adversary, more strong than what we need... 19:04:56 we are modifying Backes' definition to model the adversary's ability to learn the key images associated with a given public key, rather than the secret key. 19:06:00 this models what happens when users hand over key images in the event of a subpoena or audit, but is allowed to keep their private keys; the auditors or legal system shouldn't gain an advantage in breaking the anonymity of other monero user's signatures 19:06:36 this way, the linkable anonymity solver reduces to an algorithm that plays the 1-more computational diffie-hellman game 19:08:22 our old proof attempted to reduce linkable anonymity to the vanilla version of decisional diffie-hellman, and that's not correct 19:51:29 Got it! The use of OMCDH allows for the use of such a linking tag oracle 19:51:44 which the master algorithm can use directly and pass to the LA player 19:52:05 Thereby avoiding the problem where the player's choice of target keys is important 20:40:09 Hmm, not sure this method works 20:41:19 It's not clear if the OMCDH player has enough information from the game to pass on to the LA player in order to set a key image for a simulated signature 20:42:12 With the OMDDH player, it made sense since the tuples received were already of the correct distribution to set ring members and key images 20:42:29 ^ suraeNoether 20:43:21 If the OMDDH player can simulate a key image corruption oracle by simply returning the corresponding tuple point (which may or may not be the DDH point), and simulating corresponding signatures correctly, would that work? 20:43:52 If the signature simulation plays nicely with such an oracle, the LA player can see that it verifies correctly 20:44:22 and the same index identification method as for the old definition would tell the OMDDH player which bit to return to finish its game 21:11:13 suraeNoether: or what if there was no key image oracle, but the OMDDH player simply returned the list of all non-target-point DDH points (R_{i,3}) to the LA player? 21:11:27 Seems to simplify the game definition a bit