Meeting summary: Monero Research Lab, 18 January 2023

Posted Tue, 24 Jan 2023, from Monero Observer

Source Article Link:

This is a comprehensive summary, with added reference links, of the MRL meeting1 from January 18th 2022, 1700 UTC.


The raw, unedited, full log file for this meeting:

230118-mrl.log (83 lines)


Note: it is possible that some relevant information may be missing from this summary; read the full log file for the complete, unedited discussion.

  • Participants: 7 (UkoeHB2, Rucknium3, rbrunner4, vtnerd5, one-horse-wagon6, dangerousfreedom7, isthmus8)

  • (1) Updates

    • (1.1) on Seraphis9:

      • UkoeHB continued cleanup of the seraphis library10 (ie. updated the legacy balance recovery stuff to support non-default hw devices)

      • dangerousfreedom was still working on the knowledge proofs

    • (1.2) on Monero Light Wallet Server11:

      • vtnerd added admin-rest-api functions to monero-lws12 and was looking forward to working on Bulletproofs++13
    • (1.3) on statistical analysis, privacy, fungibility, P2Pool research14:

      • Rucknium did some historical analysis of the P2Pool outputs issue15 and how that affects the privacy of non-mining users

      • ishtmus has been doing housekeeping on the fungibility defect labeling framework and other drafts

  • (2) Open discussions

    • (2.1) on Seraphis9:

      • UkoeHB attempted to initiate a discussion about the tradeoff/issue of having seraphis tx implementations in separate structures versus the alternative of making every tx component a variant
    • (2.2) on OSPEAD16 and MAGIC Monero Fund17:

      • Rucknium was still waiting for ArticMine’s feedback on his draft: it’s been 4 months so at some point I will just have to implement the plan in the document hyc and isthmus gave a green light to the general plan18

      • Rucknium also noted that OSPEAD will have some blind spots due to lack of C++ support after other members of the MAGIC Monero Committee voted to close mj’s fundraiser19 due to a lack of funds raised after two months

      • UkoeHB was wondering how much code is needed to get OSPEAD in shape; Rucknium shared a very rough guess: the total number of C++ lines that would need to be written for tasks 1 - 3 there is…maybe 2k

      • isthmus was curious if the analysis code could be written in something other than C++; Rucknium thought that a fast language like C, Rust, and even Fortran would be nice and revealed that he is planning to write it in R; hyc noted that Fortran might actually be most appropriate for the job

      • rbrunner suggested a somewhat pragmatic first attempt to get ‘something’ better than now out of the door; Rucknium agreed and underlined that not having fast code doesn’t stop the project: It creates some blind spots. I will make it work with the resources that we have.

Let me know if you find this kind of report helpful.

Feedback, edits always welcome @/about.


  1. /monero-research-lab-meeting-18-january-2023/ 








  9.  2

  10. /ukoehb-submits-long-term-seraphis-library-ccs-proposal/ 






  16. /rucknium-ospead-ccs-proposal/ 


  18. /rucknium-publishes-ospead-fully-specified-estimation-plan/ 


License: CC BY 4.0, no changes were made to the article.