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