00:52:55 <atomfried[m]> could this proposal be changed to researching an alternative, like seraphis etc?
00:52:55 <atomfried[m]> https://ccs.getmonero.org/proposals/cypherstack-sarang-triptych-research.html
02:07:09 <xyy> how's this channel different from "Monero Dev"?
02:07:10 <xyy> is this more experimental?
02:07:49 <nikg83[m]> > <@atomfried:matrix.org> could this proposal be changed to researching an alternative, like seraphis etc?
02:07:49 <nikg83[m]> > https://ccs.getmonero.org/proposals/cypherstack-sarang-triptych-research.html
02:07:49 <nikg83[m]> Inmho, we should finish triptych multisig on paper and then decide if it’s usable/acceptable 
02:08:31 <moneromooo> It used to be about research specifically, but it now veered towards engineering. There's a large overlap.
02:10:33 <Rucknium[m]> nikg83: Isn't Triptych multisig finished on paper?
02:13:16 <nikg83[m]> Rucknium[m]: Documentation or poc is available? 
02:19:19 <Rucknium[m]> I'm going to bring this up at the next MRL meeting: Any CCS-funded work that is done "for" MRL by an "external" entity like CypherStack is managed by an extremely nebulous process/entity on the MRL side.
02:21:15 <Rucknium[m]> Some nebulosity is fine, but we are really pushing the limits here. The cloud is turning into just thin air.
06:37:33 <Reuben[m]> Inge I'm assuming you mean Halo2 on Orchard ? We are following but it's semi opaque esp with regards to performance. Interesting though. I still have my fingers crossed for something simple like Groth Bootle but extends to global anon sets. Most research nowadays that I have seen seem to veer towards the more complex general purpose zkp which is understandable I guess.
08:17:02 <Inge> Reuben[m]: yes that was what I meant. And their anon sets are tempting - but perhaps 30-60k-ish moves away from "shell game" to practically untraceable
08:37:55 <Rucknium[m]> Reuben: Inge Noob question:  How would anonymity sets of 30k-60k affect transaction size and miner/node validation?
08:43:31 <Inge> Rucknium[m]: it depends on the algorithm. With triptych/lelantus/omniring etc.. there is a logarithmig growth in transaction size - unfortunately, there is a linear growth in validation time
08:44:24 <Halver[m]> <jberman[m]> "np :) this is also a great vid..." <- Indeed a great video. Very much appreciated. Thanks.
08:44:24 <Halver[m]> https://github.com/noncesense-research-lab/Konferenco2019
08:44:31 <Inge> xyy: monero-dev is related to the day to day programming. This channel is more talk about ongoing research for future development :)
08:45:13 <Halver[m]> > <@jberman:matrix.org> np :) this is also a great vid by isthmus discussing the topic if you're interested: https://youtu.be/XIrqyxU3k5Q could be mistaken but I believe the validation was added after that research
08:45:13 <Halver[m]>  * Indeed a great video. Very much appreciated. Thanks.
08:45:13 <Halver[m]> Additionnal related stuff (slides etc) is here :
08:45:13 <Halver[m]> https://github.com/noncesense-research-lab/Konferenco2019
08:47:51 <Inge> Rucknium[m]: What Reuben is talking about is finding efficient batching that could improve the verification time, possibly allowing for huge anonymity sets 
08:49:07 <Rucknium[m]> But would tx sizes explode at rate log(N)?
08:49:38 <Halver[m]>  * Indeed a great video. Very much appreciated. Thanks.
08:49:38 <Halver[m]> Additionnal related stuff (slides, graphics, etc) is here :
08:49:38 <Halver[m]> https://github.com/noncesense-research-lab/Konferenco2019
08:51:26 <Rucknium[m]> I guess it wouldn't be that bad:
08:51:26 <Rucknium[m]> log(30000)/log(11) - 1 = 3.3 times larger, maybe?
09:11:37 <Inge> Rucknium[m]: and current tx sizes are down almost 10x from pre-bulletproofs
09:11:55 <Inge> 12KB transactions was the norm
09:19:36 <Rucknium[m]> If you go to 30k mixins, then enforcing a probability distribution for the mixin selection algorithm  by blockchain consensus rules would almost certainly be necessary since any deviation from the standard reference wallet's  implementation would stick out like a sore thumb.
13:05:21 <sgp_[m]> <Rucknium[m]> "I'm going to bring this up at..." <- This really seems like something that's better for -community since it's CCS related. MRL has always been quite open. It's not like MRL is a real entity or anything anyway
13:06:27 <sgp_[m]> There's a community meeting you can bring CCS related stuff in later today
13:06:32 <sgp_[m]> * related stuff up in later
13:22:01 <atomfried[m]> <sgp_[m]> "There's a community meeting..." <- is there a channel for such stuff? because my take on that is the more strict we are doing such stuff, the more "bureaucracy" and drama we introduce when it comes to CCS's and giving money to researchers, the less interesting it gets to work for MRL and researchers will just turn to other projects because of this, i know this is not the right channel for such discussions, so which
13:22:01 <atomfried[m]> one is the right one?
13:22:51 <sgp_[m]> atomfried[m]: #monero-community:monero.social 
13:23:03 <sgp_[m]> Best to keep this channel as devoid of that sort of stuff as possible
17:00:05 <gingeropolous> Rucknium[m], i ponder at which ringsize a uniform distribution would be best?
17:00:23 <gingeropolous> because at some n, perhaps the best thing is that no statistical test would work
17:04:12 <Rucknium[m]> I think ring size = N , where N = entire UTXO set of Monero. Then that would be the point that uniform would be a good idea 😉
17:04:47 <gingeropolous> lulz, roight roight.
17:04:59 <Rucknium[m]> A statistical test against a uniform distribution is a test like any other. There is not much inherently special about uniform.
17:06:04 <gingeropolous> i think statistical test for goodness of fit to a model would be really interesting, like as consensus. Basically, at this point an ideal thing would be a statistical test that is computationally cheap
17:07:58 <gingeropolous> however, if we stick with a front heavy distribution, making a tx using an input from the head of the chain will theo always be easier
17:08:08 <gingeropolous> and the older your output is, the more times you gotta roll
21:46:40 <jberman[m]> Computationally cheap method of verifying a ring's distribution fits the expected distribution: https://github.com/monero-project/research-lab/issues/86#issuecomment-921805298
21:55:35 <jberman[m]> constructing tx's via that method would probably be not so great for very large ring sizes (would need to re-roll a bunch), I'm guessing there is probably a formula to not need to re-roll at all. verification would be quick though regardless
22:01:44 <jberman[m]> I could write up a separate issue that more clearly explains how that method works with charts and stuff if that would be useful
22:03:43 <Rucknium[m]> jberman: I think it would be useful to simulate a distribution of, say, one million such rings constructed and then look at the mean, variance, skew, and a K-S statistic compared to the intended distribution
22:05:02 <Rucknium[m]> That is what I did for my K-S-test-based rejection method. Setting rejection threshold at p < 0.05, the mean, variance, and skew were changed by about 1% compared to the target distribution. I suppose I could post the code. 
22:05:16 <Rucknium[m]> Yeah, maybe you should make a separate issue and we can post our code and compare results.
22:06:20 <jberman[m]> That `special_selection_results.zip`file is a csv with 2 columns (outputs selected with that method, and outputs selected pure gamma), and 1.1mn rows 
22:07:00 <jberman[m]> will run some more tests over it
22:08:04 <Rucknium[m]> We need to get that statistical server hardware funded so gingeropolous can put it together and improve collaborative workflow.
22:15:32 <sakshamio[m]> Can we not do this analysis over google colab? 
22:16:05 <sakshamio[m]> Provides free gpus/tpus for such processing 
22:16:30 <sakshamio[m]> Plus the notebooks are collaborative 
22:19:25 <Rucknium[m]> sakshamio[m]: Some analysis may be sensitive and we don't want Google having access to it.
22:20:32 <Rucknium[m]> jberman: Welp, here's R's C implementation of the K-S test, I think. If you wanted to try to do a C++ version. There are probably other fast implementations out there, in native C++ maybe.
22:20:32 <Rucknium[m]> https://github.com/wch/r-source/blob/trunk/src/library/stats/src/ks.c