Meeting summary: Monero Research Lab, 18 January 2023

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

Logs

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

230118-mrl.log (83 lines)

Summary

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 (UkoeHB², Rucknium³, rbrunner⁴, vtnerd⁵, one-horse-wagon⁶, dangerousfreedom⁷, isthmus⁸)

• (1) Updates

  • (1.1) on Seraphis⁹:

    • UkoeHB continued cleanup of the seraphis library¹⁰ (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 Server¹¹:

    • vtnerd added admin-rest-api functions to monero-lws¹² and was looking forward to working on Bulletproofs++¹³

  • (1.3) on statistical analysis, privacy, fungibility, P2Pool research¹⁴:

    • Rucknium did some historical analysis of the P2Pool outputs issue¹⁵ 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 Seraphis⁹:

    • 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 OSPEAD¹⁶ and MAGIC Monero Fund¹⁷:

    • 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 plan¹⁸

    • 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 fundraiser¹⁹ 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.

-3RA