Source Article Link: https://monero.observer/meeting-log-summary-monero-research-lab-meeting-22-june-2022/

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from June 22nd 2022, 1700 UTC.

Logs

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

220622-mrl.log (71 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: 11 (UkoeHB², rbrunner³, jberman⁴, Rucknium⁵, tobtoht⁶, ooo123ooo1234567⁷, ArticMine⁸, SerHack⁹, selsta¹⁰, ofrnxmr¹¹, sech1¹²)

• (1) Updates

  • (1.1) on statistical analysis and the decoy selection algorithm:

  • Rucknium reported writing an R implementation based on mj-xmr’s Python implementation of the wallet2 decoy selection algorithm¹³

  • (1.2) on Monero fixes and the upcoming network upgrade:

  • jberman finished the Ledger integration and was almost done reviewing 8076¹⁴; he also announced plans to submit a new CCS soon

  • (1.3) on Seraphis¹⁵, Jamtis¹⁶ and MoneroKon22 presentations:

  • UkoeHB reported running some basic unit tests of enote scanning and noted that although there are various todos to address, currently there is enough code in his Seraphis library to begin writing a wallet

  • jberman was happy with how the recent MoneroKon22 presentation on Seraphis/Jamtis features¹⁷ went

  • UkoeHB was hopeful that a video of his MoneroKon22 presentation about Seraphis balance recovery¹⁸ would become available at some point

  • ArticMine mentioned his own Monerokon22 presentation (On The Security and Ecological Sustainability of Monero¹⁹), before announcing his plans to start working on a comprehensive overview of the whole fee, scaling, and related security and spam issues

  • Rucknium suggested ArticMine should reach out to endor00, as they are currently working on an analysis of the Monero “security budget”

• (2) Open discussions

  • (2.1) on the persistent many-input transactions observed since last fall:

  • Rucknium mentioned the ring caching possibility, that was previously suggested by jberman

  • ooo123ooo1234567 didn’t think the issue of broken tx relay and harmful edge case for ring signature cache was particularly interesting to discuss from a research point of view

  • (2.2) on reasons behind the HF²⁰ delay:

  • selsta proposed a 2-week HF delay that would move the fork height from 2668888 to 2678888, after mentioning that the auditors were planning to send a draft last Friday, but he wasn’t aware of any updates

  • UkoeHB and jberman had no objections, but jberman suggested postponing the delay until there was better clarity regarding multisig, which was tied up by a 3rd party

  • ArticMine questioned the proposed length of the delay

  • selsta suggested that a final decision should be taken during the next dev meeting (date TBD); ArticMine agreed;

  • Rucknium proposed keeping the current date and delaying the multisig fix to a post-HF release; ofrnxmr agreed; selsta stressed the importance of giving everyone enough time to update

  • jberman agreed with ooo123ooo1234567: HF date should be set after code is ready, not before

  • selsta confirmed that the code is almost ready, specified that the remaining tasks were 1) trezor firmware update date and 2) ledger finishing integration and stated that the HF is not months away

  • selsta pointed out that since luigi was also unavailable for a bit, the 2 weeks delay is the only viable option

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

Feedback, edits always welcome @/about.

-3RA

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