Source Article Link: https://monero.observer/meeting-log-summary-monero-research-lab-meeting-8-march-2023/
This is a comprehensive summary, with added reference links, of the MRL meeting1 from March 8th 2023, 1700 UTC.
The raw, unedited, full log file for this meeting:
230308-mrl.log (111 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: 16 (ghostway2, shalit3, UkoeHB4, CasCremers5, bewa_c6, dangerousfreedom7, ArticMine8, Rucknium9, jlo10, hbs11, rbrunner12, blankpage13, vtnerd14, xmrack15, AlexLocalMonero16, tevador17)
(1) Main topics
(1.1) on the new ‘A Holistic Security Analysis of Monero Transactions’ paper18:
UkoeHB reminded everyone that the authors of the new preprint are attending this meeting to discuss it and answer questions [CasCremers6, bewa_c7, jlo11]
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 issues19 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 MoneroFund20 or the CCS21; 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 Seraphis22; 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 (JAMTIS23) 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 protocol24:
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 cycle25; 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
Let me know if you find this kind of report helpful.
Feedback, edits always welcome @/about.
License: CC BY 4.0, no changes were made to the article.