00:28:26 <sarang> Now that suraeNoether has given his thumbs-up for the new security model and I am conducting my final review, getting confirmation of Teserakt's availability is the next step
00:28:47 <sarang> I am personally of the opinion that a math+code review by a single quality team is sufficient, but it's not my decision
00:29:00 <sarang> ^ selsta
00:29:25 <selsta> ok nice
00:29:57 <sarang> I made some efficiency improvements to the CLSAG verification C++ code that would need to get integrated into mooo's branch as well, but that's straightforward
00:30:13 <sarang> IMO they're worth the 5% speedup :)
00:30:32 <selsta> Looks like CLSAG is alive again :D
00:30:37 <sarang> It was never dead
00:30:44 <moneromooo> Riiiings...
00:30:48 <sarang> but got stuck in a loop of improving the security model :/
00:30:59 <sarang> FWIW the algorithms didn't change with the updated security model
00:31:17 <sarang> (there are minor algorithm changes relating to the higher-level transaction model, but whatever)
00:32:58 <sarang> moneromooo: did I share my updated branch with you, that included the speedup?
00:33:04 <sarang> I thought I did, but perhaps not
00:33:15 <moneromooo> You did, but said you might still change something.
00:33:38 <sarang> Did I now...
00:33:46 <sarang> This is the branch I meant: https://github.com/SarangNoether/monero/tree/clsag-optimized
00:33:55 <moneromooo> It's ready to merge then ?
00:33:57 <sarang> It's been rebased so the test suite could run properly
00:34:35 <sarang> It's ready to merge unless anyone else wants to take a look at it first
00:34:46 <sarang> AFAIK nobody has indicated they wanted to, since I brought it up last
00:35:30 <sarang> I'll touch base with Derek tomorrow and confirm Teserakt's availability in the near future
03:00:24 <gingeropolous> ok how many rings this CLSAG gonna have
03:04:33 <UkoeHB_> same amnt i think
03:04:39 <UkoeHB_> wait how many rings lol
03:04:40 <UkoeHB_> 1
05:16:33 <smooth> to rule them all
12:00:33 <sarang> Sigh... those puns...
13:57:19 <fluffypony> oh wow
13:57:20 <fluffypony> this is the best
13:57:20 <fluffypony> https://totalcoin.io/market/coin/xmr
13:57:30 <fluffypony> "XMR is a fork of Bitcoin and was created by Riccardo Spagni, Daniel Bernstein and Francisco Cabanas"
13:57:36 <fluffypony> thanks, djb!
13:58:25 <moneromooo> You're welcome.
13:59:30 <needmonero90> fluffypony: plis introduce me to djb
13:59:57 <fluffypony> lol
14:02:36 <sarang> -__-
14:02:51 <sech1> "<fluffypony> thanks, djb!
14:02:51 <sech1> <moneromooo> You're welcome" moneromooo just deanonymized himself, haha
14:04:18 <moneromooo> I know nothing about cryptography (and I'm not saying that to poo-poo djb :P)
14:08:45 <fluffypony> that's exactly what djb would say
18:52:43 <dEBRUYNE> If any of you feels like answering here -> https://twitter.com/realSidhuJag/status/1237081958544330754
18:52:46 <dEBRUYNE> Would be appreciated
19:23:07 <sarang> The curve is not prime order
19:23:18 <sarang> The group in which we work is prime order
19:24:25 <sarang> There are techniques like order checks and offsets that can be used to assert subgroup membership
19:25:17 <sarang> However, I'm assuming that "proofs of the curve" is intended to mean "proofs of constructions that use the prime-order curve group"
19:25:24 <sarang> (such proofs assume a prime-order group)
19:46:59 <xmrmatterbridge> <rehrar> oof
19:47:09 <sarang> ?
20:22:43 <rehrar> sarang coronavirus could impend research. How are we going to get you money?
20:22:54 <rehrar> Oh wait, Monero can do many things.
20:22:56 <sarang> ?
20:23:01 <sarang> oh ha
20:23:33 <sarang> (about the monero part, not the virus part...)
20:24:47 <sarang> Oh, and I was asked about whether join-type operations would be possible with some of the next-gen protocol ideas
20:25:12 <sarang> Triptych-1 should work just fine with such operations
20:25:22 <sarang> Triptych-2 is an open question, but I have some ideas
20:28:37 <sarang> Funding request is posted: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/131
20:28:48 <sarang> Comments / questions / emoji are requested!
21:28:29 <dEBRUYNE> sarang: Thanks for clarifying
21:28:40 <dEBRUYNE> sarang: Do you have an ELI5 of the differences between triptych-1 and triptych-2?
21:40:56 <sarang> Triptych-1 uses one proof per spent input, along with the same commitment-offset technique we use now to assert balance
21:42:00 <sarang> Triptych-2 uses a single proof for all inputs, and directly integrates the balance check without the need for commitment offsets
21:42:54 <sarang> The hardness assumption used in Triptych-2 is nonstandard
21:44:06 <Inge-> so T1 is O(n) and T2 is O(log(n)) .. kinda? but T2 is not as verifiably (or verified) sound as T1?
21:44:25 <sarang> Both use proofs that scale in size logarithmically with the ring size
21:45:12 <Inge-> ok but T2 scales better for multiple inputs?
21:45:14 <sarang> But the _number_ of proofs required in a transaction differs
21:45:38 <sarang> Let me pull up a plot to show simulations using real chain data; one sec
21:46:08 <sarang> https://usercontent.irccloud-cdn.com/file/TV5jhRc7/size.png
21:46:44 <sarang> This shows the different size scaling between a few protocol proposals, using the input/output structure from the actual chain post-bulletproofs
21:47:14 <sarang> The x-axis is the ring size used in the simulations
21:47:34 <sarang> All of them scale logarithmically, so it shows as linear on this plot
21:47:45 <sarang> (this plot will appear in the Triptych-2 preprint)
21:48:11 <sarang> https://usercontent.irccloud-cdn.com/file/MYXDVZmW/time.png
21:48:26 <sarang> This plot estimates the total verification time for that same data range, as a function of ring size
21:48:37 <sarang> Note that while RCT3 wins for size, it loses for time
21:48:48 <sarang> Triptych-1 and Triptych-2 are just about tied for time
21:49:36 <sarang> Verification for all the proposals is linear (with room for batching), but the x-axis is logarithmic here
21:50:44 <Inge-> And the current approach would be so much larger/slower that it doesn't make sense to fit into the plots?
21:51:45 <sarang> Yeah, it'd fly off the chart very quickly
21:53:54 <sarang> Hopefully those plots show that "which protocol wins" is a tricky question to answer
21:54:32 <Inge-> yes. And I must admit I have seen them before so it should have stuck by now :)
21:54:42 <sarang> (oh: that time plot accounts for per-block batching, which is how BPs are handled now)
21:55:05 <sarang> Yeah, these are the same data that I showed previously, redone in gnuplot to be easier to read for the preprint
21:58:07 <Inge-> Do we have any thoughts on silly large ring sigs vs something more akin to zk-snarks (if that was the one without the setup)
21:58:35 <sarang> You mean using an accumulator vs. specified anonymity sets?
21:59:04 <sarang> I don't know of a proving system that would give the necessary efficiency
21:59:22 <Inge-> I think that is what I mean, but with smaller words :D
22:00:05 <sarang> There was a Stanford presentation about using a new polynomial commitment scheme for smaller trustless proving, but the "efficient version" of that assumed some things about certain hyperelliptic curves that turned out not to be true :(
22:00:38 <Inge-> ah ok so we are still in the "untrusted setups are too expensive" state
22:00:51 <sarang> For accumulator-based proofs? As far as I know, yes
22:00:59 <sarang> for some reasonable definition of "expensive"
22:02:36 <sarang> Realistically, multisig is the big thing to be worked out regarding these
22:02:49 <sarang> Since the underlying math becomes much different
22:03:25 <Inge-> "accumulator-based proofs" = ZEC zk-stark/snark model,   "specified anonymity set" = monero ring signature ?
22:03:30 <Inge-> (i.e. as examples of implementations)
22:03:59 <sarang> In current implementations, yes, roughly speaking
22:04:22 <sarang> (the usual caveat that proving systems can be general, and show things other than accumulator status, etc.)
22:04:38 <Inge-> I should probably go to bed instead of showing off my ignorance :D
22:04:41 <Inge-> thanks :)
22:04:45 <sarang> No problem!
22:05:19 <sarang> I only mention that clarification because I think there's a general view that "SNARK == full anonymity"... but really it's "SNARK used for particular transaction model == cool accumulator stuff"
22:05:45 <Inge-> Yes, us illiterate brutes have some challenges seeing the finer points
22:05:47 <sarang> Heck, I'm sure you could build a specified-anonymity SNARK-based transaction model akin to what Monero uses too
22:06:00 <sarang> Nonsense!
22:07:09 <sarang> Oh, and I should add that if there's a decision to move to much larger anonymity sets, there would need to be decisions made about how to select them, whether to use fixed-size epochs, how to represent them, etc.
22:07:19 <sarang> There are many options there
22:10:50 <Inge-> and many pitfalls
22:11:22 <sarang> Well, using fixed epochs brings some of the benefits suggested by Miller et al. in their earlier paper on tracing
22:11:55 <sarang> Using something like a hash representation could help mitigate the possibility of remote node tomfoolery
22:11:57 <sarang> etc.
22:12:24 <sarang> And using deterministic shuffling (another Miller et al. suggestion) prevents miner shenanigans with block packing
22:12:48 <Inge-> I'm looking forward to what the future brings for private cryptocurrency. It will be an interesting ride for sure.
22:23:49 <rehrar> Sarang so you're saying we need the mix, shuffle, round the double, back, slide, on the ride?