could this proposal be changed to researching an alternative, like seraphis etc?

how's this channel different from "Monero Dev"?

is this more experimental?

> <@atomfried:matrix.org> could this proposal be changed to researching an alternative, like seraphis etc?

> ccs.getmonero.org/proposals/cypherstack-sarang-triptych-research.html

Inmho, we should finish triptych multisig on paper and then decide if it’s usable/acceptable

It used to be about research specifically, but it now veered towards engineering. There's a large overlap.

nikg83: Isn't Triptych multisig finished on paper?

Rucknium[m]: Documentation or poc is available?

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.

Some nebulosity is fine, but we are really pushing the limits here. The cloud is turning into just thin air.

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.

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

Reuben: Inge Noob question: How would anonymity sets of 30k-60k affect transaction size and miner/node validation?

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

<jberman[m]> "np :) this is also a great vid..." <- Indeed a great video. Very much appreciated. Thanks.

xyy: monero-dev is related to the day to day programming. This channel is more talk about ongoing research for future development :)

> <@jberman:matrix.org> np :) this is also a great vid by isthmus discussing the topic if you're interested: youtu.be/XIrqyxU3k5Q could be mistaken but I believe the validation was added after that research

* Indeed a great video. Very much appreciated. Thanks.

Additionnal related stuff (slides etc) is here :

Rucknium[m]: What Reuben is talking about is finding efficient batching that could improve the verification time, possibly allowing for huge anonymity sets

But would tx sizes explode at rate log(N)?

* Indeed a great video. Very much appreciated. Thanks.

Additionnal related stuff (slides, graphics, etc) is here :

I guess it wouldn't be that bad:

log(30000)/log(11) - 1 = 3.3 times larger, maybe?

Rucknium[m]: and current tx sizes are down almost 10x from pre-bulletproofs

12KB transactions was the norm

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.

<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

There's a community meeting you can bring CCS related stuff in later today

* related stuff up in later

<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

one is the right one?

atomfried[m]: #monero-community:monero.social

Best to keep this channel as devoid of that sort of stuff as possible

Rucknium[m], i ponder at which ringsize a uniform distribution would be best?

because at some n, perhaps the best thing is that no statistical test would work

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 😉

lulz, roight roight.

A statistical test against a uniform distribution is a test like any other. There is not much inherently special about uniform.

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

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

and the older your output is, the more times you gotta roll

Computationally cheap method of verifying a ring's distribution fits the expected distribution: monero-project/research-lab #86#issuecomment-921805298

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

I could write up a separate issue that more clearly explains how that method works with charts and stuff if that would be useful

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

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.

Yeah, maybe you should make a separate issue and we can post our code and compare results.

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

will run some more tests over it

We need to get that statistical server hardware funded so gingeropolous can put it together and improve collaborative workflow.

Can we not do this analysis over google colab?

Provides free gpus/tpus for such processing

Plus the notebooks are collaborative

sakshamio[m]: Some analysis may be sensitive and we don't want Google having access to it.

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.