00:03:01 The crossover happens between 32 and 64 00:20:09 Crossover? Do you mean verification time for 64-ring size triptych is greater than 11-ring CLSAG, while 32-ring is less? 00:38:50 Do verification estimates include the time to decompress ring members (one time keys and commitments)? They are stored compressed in the database 00:42:58 If you really mean decompress, it's trivial. If you mean lookup, it depends so much on I/O latency that it doesn't really make sense. 00:45:13 They include the decompression 00:46:23 Oh, wait. You mean 32 byte to ge_p3 ? Nevermind then... 00:47:10 Yes that's what I meant 01:07:42 Whoops, had the wrong CLSAG/MLSAG ring param 01:07:51 https://www.irccloud.com/pastebin/bkgjejAT 01:07:55 ^ fixed 01:08:44 So... even faster now ? :) 01:11:01 Is that version with one multiexp, or still using several ? 01:12:03 Still several 01:12:12 <[keybase] seddd>: Tript64 only taking 2x clsag time O.O O.O gotta love log-scaling functions 01:13:29 <[keybase] seddd>: v exciting, good work sarang! 01:18:09 moneromooo: those numbers are on a faster machine than before :) 01:18:17 Builds faster 01:18:21 Etc. 01:21:20 Thanks sarang. These numbers back up my original skepticism about ring sizes >128. Could we even accept >64? 01:21:33 <[keybase] seddd>: one question: is D_precomp offset as input to the key image? re: https://github.com/moneromooo-monero/bitmonero/blob/clsag/src/ringct/rctSigs.cpp#L208 01:23:28 <[keybase] seddd>: D* not D_precomp 01:30:21 UkoeHB_: we'll have to see, once it's better optimized and properly accounts for batching 01:31:04 seddd: the standard key image is computed the same as previously 01:33:01 <[keybase] seddd>: ok, so is D the key image for the decoy keys? confused because thought I was the key image, am I being dumb? 01:34:55 Yes D is the auxiliary key image for the commitment to zero 01:35:42 And the offset is for storage in the blockchain. Do mul8 during verification, which ensures it's in the right elliptic curve subgroup 01:36:01 <[keybase] seddd>: thanks UkoeHB_ :) 01:38:09 The precomp terms are used for later internal point operations 02:14:29 <[keybase] seddd>: thanks sarang :) 03:15:35 I am curious what bridge is this room using for keybase? Matterbridge? And would it be possible to speak with bridge maintainer. It would be interesting to set uo a similar thing for the kovri/sekreta channeks. Cheers. 07:51:55 https://github.com/monero-project/research-lab/issues/73 08:15:03 I feel like I heard that idea somewhere else, and maybe it has been rejected before. Anyway, bringing it back 16:21:26 Additional optimizations to Triptych verification: https://github.com/SarangNoether/monero/commit/20e581df01dc273d39ab754899ba6a7f0e46a9f7 16:22:25 Brings 16-Triptych verification down from 4070 us to 3140 us 16:22:51 (On the same machine, 11-CLSAG is 5659 us and 11-MLSAG is 6789 us) 16:23:13 This does not account for batching 16:24:26 32-Triptych becomes 5300 us, and 64-Triptych becomes 9460 us 16:28:27 Did you try pippenger out of curiosity ? 16:30:14 Not yet. I still have work to do on multiexp stuff, including algorithm selection and generator cachine 16:30:19 s/cachine/caching 16:30:19 sarang meant to say: Not yet. I still have work to do on multiexp stuff, including algorithm selection and generator caching 16:30:35 FWIW the multiexp data entries have a ctor that do the frombytes for you. 16:30:50 32- and 64-Triptych is still Ring Signatures, basically? 16:31:19 Triptych is a zero-knowledge proving system that is used as a multidimensional linkable ring signature 16:31:40 At some point the term "ring signature" becomes more fuzzy, since the security definitions change a bit 16:32:03 are you coding up Triptych because it is the most promising of the new RingCT schemes or because you wrote the paper for it and want the timing? 16:32:08 If you mean "prover-specified signer ambiguity set" then yes 16:32:32 I think it's currently quite promising, and wanted actual data for comparison 16:32:46 ok, it does indeed sound promising 16:32:57 Ok, so for purposes of privacy, can I in laymans terms get a grasp on e.g. n-Triptych vs 11-Bulletproofs vs Zcash? 16:33:13 Bulletproofs serve an entirely different purpose in the transaction protocol from the signatures 16:33:45 oh wait. again *facepalm* never mind 16:34:05 restating: Ok, so for purposes of privacy, can I in laymans terms get a grasp on e.g. n-Triptych vs 11-ring sigs of today vs Zcash? <-- better 16:34:24 Depends entirely on the risk/threat model 16:34:54 A ring signature, absent external data, provides signer ambiguity among its specified input set 16:35:24 and zcash does the sam, but the "input set" is basically the entire set of all existing transactions? 16:35:57 If you're talking strictly about shielded operations only (with no transparent interactions), then (absent external information) the ambiguity set is all previous shielded outputs 16:36:02 But 16:36:10 I am. 16:36:38 Much like how many older Monero outputs can be marked as proven-spent or likely-spent, there are related heuristics that can be applied to Zcash transparent operations too 16:36:49 right 16:36:56 So "all previous outputs" is not really accurate either 16:37:05 All depends on how you operate 16:37:34 That being said, the "safe" set of possible outputs for Zcash is very large 16:38:29 Worth noting again that the size of the ambiguity is important, but certainly not the only thing that impacts privacy in practice 16:43:29 moneromooo: looks like Pippenger doesn't take effect until ringsize 128 16:43:50 at least according to the data you had for bulletproofs testing 16:46:51 Hmm wait, I might be misreading how the limits are used 16:46:55 * sarang checks again 16:52:07 Straus/Pippenger crossover is at N=32 16:52:23 Really depends whether the number of scalar/point pairs is the same for MLSAG and triptych. 16:52:30 (per ring member) 16:53:07 Caching might affect this crossover once implemented 16:53:24 Triptych reduces to a single multiexp 16:55:56 static inline rct::key multiexp(const std::vector &data, size_t HiGi_size) 16:56:19 yep 17:02:59 This comparison data is already interesting, even if not fully optimized 17:03:58 So far, it indicates that 16-Triptych runs in 46% of the time of 11-MLSAG, and 55% of the time of 11-CLSAG 19:34:51 Timing comparison: https://usercontent.irccloud-cdn.com/file/Q4H8BTy9/timing.png 19:35:15 Size comparison: https://usercontent.irccloud-cdn.com/file/cNTwOQ6M/size.png 19:35:48 Gray lines are centered at the 11-MLSAG point on each plot as a visual guide 19:38:30 nice 19:39:37 so triptych always wins re: verification time 19:39:56 So the intersection of the Triptych line and the horizontal gray line shows the point at which Triptych exceeds the current size/time of 11-MLSAG 19:40:18 sarang: bulletproofs had a nice blog post written by you, I think Triptych would also be worthy of a blog post :) 19:40:35 once you have the numbers 19:40:50 There are still some additional optimizations to mak 19:40:53 s/mak/make 19:40:53 sarang meant to say: There are still some additional optimizations to make 19:41:07 I wanted to have these plots available to give at least an initial comparison 19:42:19 selsta: +1 19:42:24 Also nice to have a blog that we can point people to 19:42:32 Even if it will likely take quite some time before implemented 19:42:43 before/if 19:43:15 But I agree; I'll write up a post once I have more finalized data 19:43:46 FWIW if multisig weren't an issue, it'd be reasonably straightforward to deploy 19:44:11 stupid multisig 19:45:10 sarang: I remember you finding a solution for multisig though 19:45:15 Or is my memory betraying me? :P 19:45:45 Yes, but it requires non-ed25519 math 19:45:56 i mean, would it be crazy to have both protocols, triptych for standard txn and a CLSAG for multisig? 19:45:59 It needs operations in general RSA groups 19:46:05 oh wait one of them requires a thing 19:46:51 Which, I guess, is difficult to implement 19:47:08 gingeropolous: That would also make transactions stand out :P 19:47:20 FWIW verification does not require any non-ed25519 math 19:47:26 well yeah, but multisigs already stand out don't they? 19:47:52 ^ : 19:48:03 Afaik no 19:48:03 no needed ;. maybe 19:48:15 i feel like semicolons are underused 19:51:33 Anyway, there are still some optimizations to be made for those numbers, including some generator caching and batching input keys across signatures from the same transaction 19:51:57 So don't treat that data as canonical by any means