monero-project / meta

A Meta Repository for General Monero Project Matters
159 stars 67 forks source link

Monero Research Lab Meeting - Wed 31 January 2024, 17:00 UTC #963

Closed Rucknium closed 3 months ago

Rucknium commented 3 months ago

Location: Libera.chat, #monero-research-lab | Matrix

Join the Monero Matrix server if you don't already have a Matrix account.

Time: 17:00 UTC Check in your timezone

Main discussion topics:

  1. Greetings

  2. Discuss: How to confirm security of Monero's multisignature protocol? Do we need mathematical security proofs, and can we get them? Info:

  3. Discuss: Exploring Trustless zk-SNARKs for Monero's payment protocol. What are the bottlenecks for potential implementation?

  4. Improvements to the decoy selection algorithm ( Decoy Selection Algorithm - Areas to Improve, Binning PoC, OSPEAD ) @j-berman @Rucknium

  5. Seraphis. ( UkoeHB's Seraphis Proof of Concept work, Seraphis repo ).

  6. MRL Meta: "Cat herding", i.e. prioritization of research areas and features. Active recruitment of technical talent, MRL structure, funding (@Rucknium & others) MoneroResearch.info repository of Monero-related research papers, Reddit discussion

  7. Any other business

  8. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

959

plowsof commented 3 months ago

Logs

< r​ucknium:monero.social > MRL meeting in this room in two hours.

< r​ucknium:monero.social > Meeting time! (oops, forgot to make the GitHub issue...)

< rbrunner > Hello

< v​tnerd:monero.social > hi

< r​ucknium:monero.social > 1) Greetings

< r​ucknium:monero.social > Here is the meeting GitHub issue: https://github.com/monero-project/meta/issues/963

< r​ucknium:monero.social > 2) Updates. What is everyone working on?

< k​ayabanerve:matrix.org > 👋

< v​tnerd:monero.social > 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

< v​tnerd:monero.social > the review of jeffro256 code looked good, but reverted some ZMQ "features"

< r​ucknium:monero.social > 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.

< r​ucknium:monero.social > Once I get the isthmus data it takes about 5 days of additional processing. Then interpret the results.

< rbrunner > https://monerofund.org/projects/ring_signature_ai gives me 500 Internal Server Error

< v​tnerd:monero.social > yeah the funding site is down, I notified sgp about it about 20 minutes ago

< rbrunner > Ok :)

< r​ucknium:monero.social > uh oh. Ok we will try to fix. Thanks for telling us

< rbrunner > But well, that's not even the Zurich fundraiser I think

< r​ucknium:monero.social > no, it's not

< v​tnerd:monero.social > yes, that link should be an older fundraiser

< r​ucknium:monero.social > 3) Discussion. What do we want to discuss?

< k​ayabanerve:matrix.org > I have misc more progress on Full Chain Membership Proofs, nothing to specifically note re: progress.

< k​ayabanerve:matrix.org > Ideally, ideally, with Vector Commitments, we can get the bulletproof to

< k​ayabanerve:matrix.org > 10 gates a scalar mul

< k​ayabanerve:matrix.org > A few gates on misc

< k​ayabanerve:matrix.org > n on set membership

< k​ayabanerve:matrix.org > Such that we reach a power of 2 where n**p where p<6 > 500m.

< k​ayabanerve:matrix.org > 50**5 is roughly that (with the power of 2 being 64).

< k​ayabanerve:matrix.org > 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).

< k​ayabanerve:matrix.org > Under current theory, ideally the FCMP circuit size will be halved from where it was prior (yet not at the above level).

< k​ayabanerve:matrix.org > So performance of that is significantly improving re: theoretical architecture.

< r​ucknium:monero.social > Nice. Does that affect verification time? Or the about the same verification time that you estimated earlier?

< k​ayabanerve:matrix.org > Verification time is linear to circuit size, and this is all further improvement goals.

< r​ucknium:monero.social > 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<clipped message

< r​ucknium:monero.social > f a general distribution are set to particular values, it is equivalent to another more specialized distribution.

< r​ucknium:monero.social > You can just search over the parameters space of the generalized distribution and you have "checked" if the specialized distribution fits better.

< r​ucknium:monero.social > The two main generalized distributions that I will try are the Generalized Extreme Value and the Feller-Pareto distributions.

< r​ucknium:monero.social > 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.

< r​ucknium:monero.social > 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.

< v​tnerd:monero.social > I was just going to ask about that, because LWS is one of the few alternate implementations of decoy selection

< r​ucknium:monero.social > Is there a list of probability distributions that can be easily added to the Monero codebase, like in boost?

_< s​gp:monero.social >__ Yes, sorry about this. I'm not sure what happened :/ But I'm actively working on this\

< r​ucknium:monero.social > 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.

< v​tnerd:monero.social > if its complex, at least provide a good re-usable API

< v​tnerd:monero.social > there's boost accumulators and boost math that have statistics functions

< v​tnerd:monero.social > thats about all I know, as I can't recall ever using either

< rbrunner > No idea either.

< r​ucknium:monero.social > 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.

< v​tnerd:monero.social > oh theres also boost special functions

< v​tnerd:monero.social > ok so your providing the reference implementation in R, and one of the C++ programmers will have to port?

< r​ucknium:monero.social > 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.

< v​tnerd:monero.social > that will work, there's a few people that can do a port (hopefully)

< r​ucknium:monero.social > Some of them have better "documentation" than others. For example....

< r​ucknium:monero.social > Feller-Pareto, which is probably the most general and most complex one: https://www.jstatsoft.org/article/view/v103i06

< r​ucknium:monero.social > Has a whole article about how to implement, including numerical stability issues.

< k​ayabanerve:matrix.org > There's also monero-serai which has its own implementation.

< r​ucknium:monero.social > 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.

< r​ucknium:monero.social > Like calculating the flow of outputs in the last year, etc

< r​ucknium:monero.social > Anything more to discuss?

< r​ucknium:monero.social > We can end the meeting here.

Automated by this