17:01:08 Meeting time! (oops, forgot to make the GitHub issue...)
17:01:53 Hello
17:01:53 hi
17:02:10 1) Greetings
17:03:24 Here is the meeting GitHub issue: https://github.com/monero-project/meta/issues/963
17:03:49 2) Updates. What is everyone working on?
17:04:34 👋
17:04:58 me: spend a lot of time doing a review of jeffro256 changes to txpool handling, and continued slowly on lws "chain hardening". about 70% sure its worth hacking lws to do this, but without it you can easily spoof chains
17:05:28 the review of jeffro256 code looked good, but reverted some ZMQ "features"
17:06:06 Me: OSPEAD. isthmus will get me some data today probably. The processing "only" took a few hundreds of GB of RAM. I hope the hardware requirements can be reduced so that the analysis is easier to reproduce by others. The MAGIC Monero Fund approved the University of Zurich research group's EAE/churning research for a fundraising.
17:06:54 Once I get the isthmus data it takes about 5 days of additional processing. Then interpret the results.
17:07:54 https://monerofund.org/projects/ring_signature_ai gives me 500 Internal Server Error
17:08:17 yeah the funding site is down, I notified sgp about it about 20 minutes ago
17:08:45 Ok :)
17:08:47 uh oh. Ok we will try to fix. Thanks for telling us
17:09:15 But well, that's not even the Zurich fundraiser I think
17:09:27 no, it's not
17:09:34 yes, that link should be an older fundraiser
17:12:13 3) Discussion. What do we want to discuss?
17:12:53 I have misc more progress on Full Chain Membership Proofs, nothing to specifically note re: progress.
17:12:53 Ideally, ideally, with Vector Commitments, we can get the bulletproof to
17:12:54 10 gates a scalar mul
17:12:54 A few gates on misc
17:12:55 n on set membership
17:12:55 Such that we reach a power of 2 where n**p where p<6 > 500m.
17:12:56 50**5 is roughly that (with the power of 2 being 64).
17:12:56 That'd make the cost of the FCMP roughly equal to 1 aggregate BP of 4 outs and 1 aggregate BP of 2 outputs (if my off-hand math is correct).
17:12:57 Under current theory, ideally the FCMP circuit size will be halved from where it was prior (yet not at the above level).
17:13:34 So performance of that is significantly improving re: theoretical architecture.
17:14:25 Nice. Does that affect verification time? Or the about the same verification time that you estimated earlier?
17:17:13 Verification time is linear to circuit size, and this is all further improvement goals.
17:22:56 Pretty much the only think left to do with OSPEAD is to fit several distribution families to the real spend age data and pick the "best" one. Maybe someone has an opinion about which ones should be tried. I plan to fit a "small" number of distributions in total, but some of those distributions are generalizations of a large number of other distributions. i.e. if the parameter(s) o f a general distribution are set to particular values, it is equivalent to another more specialized distribution.
17:23:35 You can just search over the parameters space of the generalized distribution and you have "checked" if the specialized distribution fits better.
17:24:23 The two main generalized distributions that I will try are the Generalized Extreme Value and the Feller-Pareto distributions.
17:25:25 I will also try the Log-Gamma (the same family that we have now for decoys, but we will get different parameter values for the more accurate data). And the Noncentral F and Right-pareto Log-normal distributions.
17:26:07 I will mind the implementation complexity of these. If a more complex distribution is only slightly better in fit than a simple one, we may want to use the simple one.
17:26:30 I was just going to ask about that, because LWS is one of the few alternate implementations of decoy selection
17:27:00 Is there a list of probability distributions that can be easily added to the Monero codebase, like in `boost`?
17:27:28 ~~ Yes, sorry about this. I'm not sure what happened :/ But I'm actively working on this\
17:27:44 Yes, so maybe if log-gamma with different parameters is almost as good as an alternative one, it is easier to just update those numbers in `wallet2` and other implementations that use log-gamma.
17:27:57 if its complex, at least provide a good re-usable API
17:28:40 there's boost accumulators and boost math that have statistics functions
17:28:59 thats about all I know, as I can't recall ever using either
17:29:31 No idea either.
17:29:31 The candidate distributions will be implemented in R. And some of those use C or C++ functions underneath. But many of them are licensed under GPL.
17:29:46 oh theres also boost special functions
17:30:42 ok so your providing the reference implementation in R, and one of the C++ programmers will have to port?
17:32:15 Maybe that is what would happen. The functions are defined mathematically. Even the most complex ones aren't hundreds of lines of code or anything.
17:33:42 that will work, there's a few people that can do a port (hopefully)
17:34:21 Some of them have better "documentation" than others. For example....
17:35:38 Feller-Pareto, which is probably the most general and most complex one: https://www.jstatsoft.org/article/view/v103i06
17:36:01 Has a whole article about how to implement, including numerical stability issues.
17:36:08 There's also monero-serai which has its own implementation.
17:37:13 This replacement would be just for the random number generation. Generating a random output index. Then everything else about the decoy selection algorithm would be the same.
17:37:31 Like calculating the flow of outputs in the last year, etc
17:40:52 Anything more to discuss?
17:43:18 We can end the meeting here.
~~