Meeting summary: Monero Research Lab, 8 March 2023

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

Logs

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

230308-mrl.log (111 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: 16 (ghostway², shalit³, UkoeHB⁴, CasCremers⁵, bewa_c⁶, dangerousfreedom⁷, ArticMine⁸, Rucknium⁹, jlo¹⁰, hbs¹¹, rbrunner¹², blankpage¹³, vtnerd¹⁴, xmrack¹⁵, AlexLocalMonero¹⁶, tevador¹⁷)

• (1) Main topics

  • (1.1) on the new ‘A Holistic Security Analysis of Monero Transactions’ paper¹⁸:

    • UkoeHB reminded everyone that the authors of the new preprint are attending this meeting to discuss it and answer questions [CasCremers⁶, bewa_c⁷, jlo¹¹]

    • CasCremers immediately opened up for questions after briefly introducing the team and the paper: we are three academics at the CISPA Helmholtz Center for Information Security in Germany; the paper tries to give a more complete analysis of the security of Monero transactions as opposed to the isolated analyses previously

    • dangerousfreedom was interested in several things: a) if there is any part of the security analysis that is not 100% clear and what they would potentially investigate next, b) if the analysis was purely theoretical, and then linked to some issues¹⁹ he found while attempting to make a ‘holistic’ analysis, wondering c) if it is worth to further investigate it in a formal way

    • CasCremers replied to dangerousfreedom’s first two questions: a) although there is a limitations section describing part of the analysis that were not completed yet that would be interesting to investigate, currently there is no project tailored towards that; and b) confirmed that the analysis is, indeed, theoretical

    • bewa_c jumped in to tackle dangerousfreedom’s last question: As stated in the limitations, we assume that we have a prime order group

    • UkoeHB noted that the format is fairly informal and that he is currently in the process of reviewing it (~1/4 through); he was curious if they found anything interesting/surprising during the research; jlo replied that on the practical side they did not find anything particularly surprising, confirming that Monero’s transaction system is secure in their model, but they did encounter many technical obstacles during the proof due to the non-standard uses of the crypto in the Monero transaction system

    • Rucknium invited the team to get funding for studying Monero multisig via MoneroFund²⁰ or the CCS²¹; CasCremers was interested in setting up a further project on Monero with PhD students

    • CasCremers acknowledged that they are not yet considering privacy in their work, underlining that removing the limitations and moving closer to the implementation is very challenging

    • Rucknium wondered what motivated the team to write the paper and focus on studying Monero; CasCremers replied that it seemed like a sizeable challenge of scientific interest from a proof technique angle

    • UkoeHB noted that he was not expecting such an impressive paper, having assumed that the task was too large for anyone to tackle; CasCremers stated that work took over a year

    • Rucknium mentioned that the Monero Project will most probably need help with creating formal security proofs for some of Seraphis²²; UkoeHB confirmed that the holistic analysis paper will be a very strong starting point for a security analysis of seraphis

    • ArticMine mentioned that extensive audit work will also be required

    • CasCremers asked about the intended timeline for Seraphis; UkoeHB shared his keenness to get security proofs done this year, as the implementation and addressing scheme (JAMTIS²³) are already done

    • CasCremers was interested and proposed discussing options in a separate mail discussion; Rucknium and UkoeHB agreed

  • (1.2) on exploring trustless zk-SNARKs for Monero’s payment protocol²⁴:

    • UkoeHB noted that there may not be enough time to discuss other agenda items and asked if anyone had a topic they wanted to discuss; AlexLocalMonero suggested MRL #100 (zk-SNARKs)

    • UkoeHB asked tevador and kayabanerve to summarize where #100 is heading

    • tevador noted that he is currently looking for curve cycles that are compatible with ed25519 and suggested that the next step would be prototyping curve trees in sage with the seraphis key format

    • UkoeHB wondered if that is different from the indirect cycle²⁵; tevador replied that he is looking for a better cycle that has 255-bit fields instead of 266 bits for performance reasons

    • ArticMine asked if the approach would require a transaction format change after Seraphis; UkoeHB stated that it would require switching out the membership proof and a bunch of implementation work to handle merkle trees

    • ArticMine wanted to know the rough size for a 2 in 2 out transaction; tevador repied that the Curve Trees demo was around 4 KB for 2/2, with 1 merged proof for both inputs

• (2) Open discussions

  • (2.1) on MoneroKon 2023²⁶:

    • blankpage invited everyone to submit proposals²⁷ to present at Monerokon in Prague in June, and suggested spreading the message to other relevant researchers

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

Feedback, edits always welcome @/about.

-3RA