15:04:03 MRL meeting in this room in two hours. 16:17:36 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/449#note_26540 for a summary of the current FCMP++ Research CCS. I'll have commentary to raise re: divisors and what the step forwards are there today. 17:00:42 Meeting time! https://github.com/monero-project/meta/issues/1086 17:00:54 1) Greetings 17:01:15 Hello 17:01:26 Hello 17:01:29 Hello 17:01:41 hello 17:01:54 howdy 17:01:58 👋 17:02:00 *waves* 17:02:04 Hello! 17:03:31 hi everyone! 17:04:13 2) Updates. What is everyone working on? 17:05:52 me: Analyzing node p2p logs, especially transaction broadcast timings. Mostly, things work the way that the code is supposed to work. 17:06:56 me: invited some guests from the firms who would like to audit the Carrot spec! Welcome to all those that joined the MRL for that reason, and thanks for your time. I'll let you know when a good time to jump in is. Otherwise, I have been working on implementation and integration with legacy scanning and balance recovery 17:08:22 We can go directly into the FCMP++/Carrot agenda item, since I think some people in the room are waiting on that. 17:08:27 3) Research Pre-Seraphis Full-Chain Membership Proofs. Reviews for Carrot. https://www.getmonero.org/2024/04/27/fcmps.html https://github.com/jeffro256/carrot/blob/master/carrot.md 17:08:40 me: continuing working on syncing the curve trees tree on the wallet side (storing minimal data necessary to sync the tree), so wallets can construct an fcmp for an owned output using the output's latest path in the tree 17:10:16 Hey all, Luna from Zellic here 17:11:09 Before the meeting, kayabaNerve posted a summary of work that has been accomplished on FCMP++ research and review: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/449#note_26540 17:11:16 Thanks, kayaba 17:13:41 I am going to pose a noob question about the Carrot review. (To guests: I'm an economist, not a cryptographer.) Is there anything "special" about addressing protocols, compared to other problems in the blockchain cryptography space? In other words, is it important that a reviewer have specific prior experience in reviewing and/or designing address protocols? 17:14:00 I believe that kayabanerve had some details to share about his FCMP work before discussion of the Carrot audit 17:14:05 hi 17:14:08 apologies for being late 17:14:12 I see . Ok thanks 17:14:59 Hello, sorry. 17:15:01 I am here, I just had to step back for a moment. 17:15:13 Welcome back :D 17:15:53 I would like to go over the FCMP++ Research summary and how that's moving forward, if amenable. 17:16:08 Of course 17:17:10 I posted the summary above. Re: divisors, we have proofs of the technique from Veridise (reviewed), yet still haven't had the R1CS finalized/audited. We prior ran out of hours and had a small extension approved, as detailed in the posted summary. 17:17:11 @Rucknium: to answer your question, previous experience in auditing addressing protocols always helps, but AFAIK it shouldn't be strictly required as long as the consensus protocol requirements are well understood by the reviewers. If I am wrong, anyone feel free to correct me 17:18:39 For the past few weeks, I've been discussing the rest of that scope with Veridise. The prior mentioned extension did start on a review and identified one potential issue. 17:19:20 The existing security proofs are for positive integers, not elements of a finite field. That leaves us needing to expand the security proofs in that regard. 17:19:50 Rucknium having only briefly looked a the Carrot proposal, at a glance it is helpful to have some familiarity with stealth address schemes in general -- as implemented in ZCash for instance. There are certain attack vectors that come up in practice (Janus attacks, DDH oracles via timing, etc) that can break privacy / add linkability but don't 17:19:50 violate the normal existential forgery considerations of address/signature schemes 17:20:17 I'd like to move forward with Veridise, who the running tally is 11k, for an additional 5k explicitly to specify taking the logarithmic derivatives (a topic brought up in CS's review) and expand the security proofs on this manner. 17:21:27 That still leaves needing to formalize the protocol encoded into the R1CS, prove it, and actually encode it into the R1CS. While we do have a quote for those scopes, that part is still being discussed and clarified a bit. I'd like to propose moving forward with what makes sense now before this gets further bottlenecked. 17:22:34 I'll also note a few meetings ago, I had a check written (yet never cashed) for an amount exceeding the amount I'm requesting now for further work on this from Veridise. I'm explicitly making this proposal now as it's a bit weird as I'm only proposing a partial continuance of the necessary scope, not the entire scope at this time. 17:22:38 kayabanerve: I'm ok with that, but what is the contingency plan if the attempt to repair the proof fails? 17:23:54 I also do see Alp is here and this is the first they're hearing of my intent to downscope our discussions from the existing quote. Hi, very sorry if this a bit blindsiding to you, I just wanted consensus from the community that the more incremental approach is an acceptable proposal before I came to y'all with this. 17:24:22 I'm also fine with that, but would we also have another player (maybe CS again) review the new security proofs afterwards? 17:24:58 BTW as a procedural matter, I'm having issues joining this room on Matrix (thus the fallback to IRC here), and monero.social homeserver registration seems disabled. I was able to join the lounge channel but not this one; am I missing an invite? 17:25:02 Rucknium: The proofs should work out. The main concern is if they work out with ideal performance. 17:25:37 Without divisors, a scalarmul is 512 multiplicative constraints with a reusable prior 256 multiplicative constraint bit decomposition. 17:25:46 LunaZellic: type out the username in the chat and I'll invite you. Sorry we've been having spam issues recently 17:25:52 ephemeral2:matrix.org, thank you! 17:26:03 With divisors, and no need for a bit constraining, it's 7. 1/110th the constraints. 17:26:25 Thank you! 17:26:41 No worries, I agree that a more incremental approach would be meaningful! 17:26:51 Of course! Sorry about the friction 17:26:57 If we need to introduce bit constraints for the field elements to satisfy the positive integer bound (if we can't relax that bound), we'd add the reusable bit decomposition. Divisors would only be 33% the size, not 1%, of the traditional method. 17:28:11 (The fact it's reusable only matters if we want to reuse the scalars. Most scalars we don't reuse so it doesn't benefit us) 17:28:13 Do you have an estimate for what percentage larger that falback would make the input proof/tx? 17:29:10 If we can relax the bound and maintain performance, presumably CS would do review again. If we prove it with additional constraints, the additional performance is of such value I'd encourage contracting CS to do their own attempt on this topic, yet that's a separate discussion. 17:29:11 I believe that the issue about finite field elements vs integers will most likely not cause a too serious issue, but would probably require some of the soundness proofs to be re-adjusted. In the worst case it can be salvaged resturcturing and adding additional contraints (hopefully not too many). 17:30:16 After we have the technique so improved, we'll still have a scope of work for the protocol encoded and the R1CS encoding. I just don't want to continue delaying any progress while the considerations there finalize. I've already deferred to the next meeting for the prior... three meetings? 17:30:27 I have seen myself and jeffro256 support kayabanerve 's proposal on an incremental extension on the divisor proof. Are there more opinions in the room? 17:30:56 At least I see nothing that speaks against it ... 17:31:19 Size wouldn't be impacted. Performance would be. It'd increase the path size (which may notably impact wallet bandwidth for anyone without wallet trees) and probably impact proof verification time 2-3x. 17:31:39 And Veridise doing it makes sense here obv since they freshly worked on it. Just for fun, who noticed the issue initially? 17:31:46 I +1 this approach as well 17:31:50 I see. Thank you. So many meanings of "size" ;) 17:32:04 Alp, thank you for expressing your support for this timeline (which you're only just now hearing of 😅) and iterating your confidence :) 17:32:25 jeffro256: Alp noted the issue in the few hours of R1CS review already done. 17:32:55 Rucknium: circuit size impacts proof size and proof time. Proof size is negligible as doubling the circuit size only adds 64 bytes to the proof. 17:33:19 We already had some support for incremental extension of around this budget at a previous meeting IIRC. 17:34:06 I also have more on the fcmp++ dev side but I'm happy to step back for jeffro256 and the fine collection of auditors they brought in person now that I've said my piece on audits. 17:34:25 I think we have loose consensus on this proposal. We can move on to the next topic since we have lots to cover ("I'd like to move forward with Veridise, who the running tally is 11k, for an additional 5k explicitly to specify taking the logarithmic derivatives (a topic brought up in CS's review) and expand the security proofs on this manner.") 17:34:57 Thanks, guests, for your patience :) 17:35:07 No, thank you! 17:35:40 Alright! Yeah I'll invite the guests to introduce themselves one by one, and give a quick elevator pitch if desired ;). Also anyone should ask questions if they have any 17:35:45 Okay! 17:36:01 Thanks for your patience 17:36:14 Luna, would you like to go? 17:36:29 Hi all, my name is Luna, and I'm the co-founder and CEO of Zellic. I've brought along with me some of my colleagues on the IRC side and we're proposing for the proof and audit of Carrot. 17:36:31 (still typing) 17:37:06 Forgot to today was Wed, sorry I'm late 17:38:54 jeffro256: Do we have a formal statement of the scope of work? Sorry if I missed it. 17:39:01 We have extensive background auditing privacy-focused cryptocurrency projects. We audited Singularity, which is essentially a Zcash clone (a dark pool). In our audit of Penumbra (Zcash-esque, we found several critical soundness bugs. We've also audited NEBRA (zk proof aggregation in gnark) and in the process we actually found two vulnerabilities in the gnark's extension of Groth16 17:39:03 that we reported and got fixed (CVE-2024-45039, CVE-2024-45040) 17:39:35 Our audit of Singularity: https://reports.zellic.io/publications/singularity 17:39:37 PDF: https://github.com/Zellic/publications/blob/master/Singularity%20-%20Zellic%20Audit%20Report.pdf 17:39:39 Penumbra audit: https://github.com/Zellic/publications/blob/master/Penumbra%20-%20Zellic%20Audit%20Report.pdf 17:40:15 Yes scope of worked for the Carrot audit is this document: https://github.com/jeffro256/carrot/blob/master/carrot.md. For all the firms, I requested general review of security of the specification and security proofs of all the properties listed in the "security properties" section 9. 17:40:32 As for myself, I'm a former vulnerability researcher, and me and my cofounder founded perfect blue, which was the top-ranked CTF team in the world in 2020, 2021, and 2023 per CTFtime. 17:40:33 I'm also a huge believer and evangelist in Monero myself and have been using and spending Monero since 2017 when I was in high school! 17:40:46 so I have an emotional connection to this proposal myself haha 17:41:01 Nice to meet you Luna! 17:41:18 As for myself, I'm a former vulnerability researcher, and me and my cofounder also founded perfect blue, which was the top-ranked CTF team in the world in 2020, 2021, and 2023 per CTFtime. 17:41:19 I'm also a huge believer and evangelist in Monero myself and have been using and spending Monero since 2017 when I was in high school! 17:41:21 17:41:23 Thanks sgp_! 17:41:25 Thanks, Luna! Anyone have any questions for Luna / Zellic ? 17:41:36 \ 17:41:37 Thanks sgp\_! 17:42:08 (Also, here is the link to the report for the issues we found with Gnark: https://www.zellic.io/blog/gnark-bug-groth16-commitments/) 17:42:50 I wanted to ask, have the members of the MRL already seen our proposal or is it mainly just jeffro256 so far? 17:42:57 LunaZellic: Do you have a specific person or person in Zellic who would likely lead the review of Carrot? Or is that not something that's decided yet? 17:43:10 It will be Malte Leip, the author of the Gnark advisory linked above. 17:43:13 person(s) 17:43:26 The second peer reviewer will be Mohit Sharma. 17:43:47 I have compiled a summary of proposals and shared it with a few members. If anyone would like the PDFs as well, please let me know. 17:44:32 Okay, if there aren't any more questions, would QuarksLabs like to jump in? 17:44:41 Hi all, Quarkslab team is here ! We prepared a text to outline our offer 17:45:24 # Why us 17:45:25 Quarkslab's team already performed a cryptographic & security assessment of the Bulletproof protocol to be used by the Monero open-source cryptocurrency (XMR) and RandomX new proof-of-work algorithm. Our team is substantial and composed of 3 PhDs, 2 master degrees in security, and 1 master degree in mathematics. 17:45:27 https://dblp.org/pid/44/1487.html 17:45:29 https://dblp.org/pid/214/8633.html 17:45:31 https://dblp.org/pid/177/2271.html 17:45:33 # References 17:45:35 - https://github.com/tari-project/bulletproofs-plus/blob/main/docs/quarkslab-audit/report.pdf 17:45:37 - https://blog.quarkslab.com/resources/2021-12-08_litecoin/21-08-872-REP.pdf 17:45:39 - https://blog.quarkslab.com/audit-of-the-mimblewimble-integration-inside-litecoin.html 17:46:06 # Audit Methodology Proposed 17:46:07 ## Discovery (3d) 17:46:09 3 days of discovery of: 17:46:11 - Adversary model for each proof 17:46:13 - Carrot construction 17:46:15 - Curve trees 17:46:17 - SoA: Original scheme + subaddress 17:46:19 - Janus attack (and other existing ones) 17:46:21 ## Proofs (~15d) 17:46:23 - Balance Recovery (~6d) 17:46:25 - Unlinkability (~2.5d) 17:46:27 # Timing 17:46:29 End November / December to start and execute is ok for us 17:47:42 Available for questions ! 17:48:54 Thank you, lyanaqb 17:49:04 Does Cypherstack want to hop in? 17:49:10 Yes, thank you! 17:49:32 We'll do the work. In exchange for Monero. 17:49:42 Let me know if I'm moving too fast, by the way, I just want to make sure to respect the guests' time 17:50:23 Brandon Goodell is with us now (surae), and we're on-boarding three more cryptographers that will be reviewing the work as well. 17:50:26 lyanaqb: Same question to you. Do you have a specific person(s) on your team who would likely be the lead(s) on this review? 17:51:21 Surae will be the primary overseer, with the bulk of the work and proving done by Freeman Slaughter (not a pseudonym), one of our new cryptographers. 17:51:35 :) 17:51:38 It will be one of the 3 Phd and an other one will be the reviewer for the quality process. 17:51:49 It will be one of the 3 PhD and an other one will be the reviewer for the quality process. 17:53:00 Diego, thanks for the input. Following up on timing information, is the turnaround time still estimated to be 3-4 months? 17:53:06 I'm also happy to take further questions. 17:53:31 No. Things have cleared up significantly since then. MRL taking their time meant we got to clear a lot of work off of our plate. 17:53:37 3 weeks more likely. 17:54:05 Alright, good to hear. 17:55:16 Guests from Trail of Bits here? 17:55:27 Hi all - thanks for having us at your meeting! I’m Lindsay, sales manager at Trail of Bits - a software security research and development firm in Cyber security with specialized expertise in blockchain, cryptographic, and application security reviews. 17:55:35 I’m joined by Tjaden, a senior security engineer on our cryptography team, as well as Chris, our principal sales engineer. 17:55:47 We’re proposing a 4 engineer-week cryptographic design review of the Carrot (Cryptonote Address on Rerandomizable-RingCT-Output Transactions) specification, which includes Janus attack resistance. This work would be completed by 2 cryptographers over 2 calendar weeks. We currently have availably to begin work this month! 17:56:11 Please see notable similar reviews include: - Zcash: https://github.com/trailofbits/publications/blob/master/reviews/Zcash.pdf -Stealth addresses: https://github.com/trailofbits/publications/blob/master/reviews/2023-02-ryanshea-practicalstealthaddresses-securityreview.pdf (Stealth address scheme for ethereum-based privacy coin - found a number of de-anonymization issues. 17:56:34 Public examples of our cryptographic design reviews to see work and deliverable we’ll produce include: -Discord https://github.com/trailofbits/publications/blob/master/reviews/2024-08-discord-dave-protocol-designreview.pdf Ockam: https://github.com/trailofbits/publications/blob/master/reviews/2023-11-ockam-designreview.pdf 17:56:42 Happy to answer any questions! 17:57:41 Nice to see you again Lindsay (Justin from MAGIC Grants here). Thanks for your proposal 17:58:17 We're glad to be here, Justin - great to be in touch again! 17:58:38 The field of companies doing such reviews seems to be bigger than I would have estimated, interesting 17:59:42 Lindsay, do you have an idea of who in your company may be the lead(s) on a review of Carrot? 18:01:00 I was assuming everyone had copies or summaries of the proposals; should I share our timeline / availability info here for convenience? 18:01:21 Seeing as the other proposers have so far in this channel. This is our first time proposing for Monero, so getting the hang of it still. 18:02:13 The project team is chosen based on each engineer’s skill set and availability, so it may vary. We have a few cryptographers in mind, but it will likely be Jim Miller, engineering director of our cryptography team, Filipe Casal, Principal Security Engineer, Fredrik Dahlgren, Principal Security Engineer, and/or Tjaden Hess, Senior Security Engineer 18:02:35 Yes, feel free to attach any info that you would like to share more openly! 18:02:44 You can share what you wish. I think jeffro256 was cautious about what to share since some firms want to keep some details non-public. I guess for competitive reasons. 18:03:06 Thanks, Lindsay 18:03:32 Note that this room is not normally invite-only as has publicly available logs 18:04:01 Note that this room is not normally invite-only and has publicly available logs 18:04:11 Yes this room is logged: https://libera.monerologs.net/monero-research-lab 18:05:59 This should've been mentioned in the emails / Slack chats but it probably good to reiterate 18:06:25 And yes, thank you, Lindsay. Finally, I welcome Ben and Alp from Veridise to join in at the moment if desired. 18:07:18 Hi all! My name is Ben, I am the CSO at Veridise 18:07:19 Veridise is a security firm that works across the blockchain tech stack, but is especially well-known for our work in ZK-circuits and in-house expertise in building and applying automated security analyses in tandem with manual reviews. We have worked with projects like the Manta Network, o1js, Linea, Succinct, and RiscZero to secure their circuits, including both extensive review s for cryptographic vulnerabilities as well as common ZK or logical errors. We worked with Monero earlier this year to help ascertain the security of a new dlog-commitments. This effort was led by Alp Bassa , who would also be leading the work on the carrot protocol 18:07:29 Monero is a community-based project, has no CEO, no premine, etc. as many of you know. R&D decisions are subject to community scrutiny :) 18:07:39 Alp joined Veridise in 2022 after spending over a decade as a mathematics professor in academia. Alp has extensively published in number theory, algebraic geometry, cryptography and coding theory. He holds a double major in computer science and mathematics and earned his PhD from the University of Duisburg-Essen. After postdoctoral positions in the Number Theory Group at the Écol e Polytechnique Fédérale de Lausanne (EPFL), the Cryptology Research Group lead by Ronald Cramer at the CWI-Amsterdam and the Coding Theory and Cryptography Group at NTU Singapore, he joined the faculty at Sabanci and Bogazici Universities in Istanbul. At Veridise, Alp works at the intersection of research and in-house tool development. He also participates in security audits, e specially those requiring a deep understanding of mathematics and cryptography. 18:08:24 We'd be happy to answer any questions about the proposal! Timeline-wise, we are expecting it to take around four weeks, and can start by in the next one to two weeks 18:08:26 We'd be happy to answer any questions about the proposal! Timeline-wise, we are expecting it to take around four weeks, and can start in the next one to two weeks 18:08:37 I should say "community input and scrutiny" 18:11:33 all of you smarties should join forces with us and we can make an ultra super mega powerful privacy protocol :D 18:12:15 Ah, but competition is good. Diego wanting to form a monopoly :P 18:12:40 *smarties* are candy. 18:13:00 I meant for Monero >:( 18:13:31 Ack. Zellic: 18:13:33 - Work will be conducted over a 4 calendar-week period 18:13:35 - Availability starts around the beginning of November, to the beginning of December at the latest 18:13:37 - Our estimate is 3 engineer-weeks of effort for the proofs and peer review, and we're also providing MRL the option for 1 additional engineer-week as an extension if it is needed. 18:13:39 One thing we want to note for the group is that the amount of time proof writing takes can vary and isn't always 100% predictable. Sometimes properties turn out to be very straightforward and easy to prove. Other times, it may turn out harder than expected or the property doesn't actually hold (i.e. a proof is impossible), and we need to instead switch to proving a variant. 18:13:41 This is tricky from a project management standpoint, and to mitigate, we'll be in constant communication with MRL as we make progress. This would mean progress updates and asking for priorities/direction from MRL. This is so MRL gets the best value out of the time as possible. 18:15:04 We think 4 engineer-weeks is a safe amount of time to get it all done; 2 is maybe possible if everything turns out to be really easy to prove. We think 3 weeks + option for 1 week extension is a good middle ground here that saves MRL budget. So that's our overall rationale 18:15:52 jeffro256: What is the approximate labor time needed to implement Carrot in code? I am just thinking about which of our racehorses here (FCMP++ R&D, coding, Carrot R&D and coding) may finish last as we think about hard fork activation timing. 18:16:08 (our understanding is that this is essentially being funded by community members and not a foundation of sorts, so cost saving is important) 18:16:17 So many wonderful people here. Thank you for attending and for your input ;). Any technical questions for specific guests? 18:16:20 In other words, how urgent is Carrot review? 18:17:37 Does kayabanerve have any questions? 18:18:20 I would greatly prefer it not to slow down the FCMP++ upgrade, and it shouldn't. In the worst case, we can release FCMP++ and keep the same addressing protocol code we have now and bring Carrot in a few months after. That shouldn't happen, but it is what it is. Even if Carrot is on time, hardware wallets might take a while to catch up so we should be open to allowing non-Carrot tx s for a few months IMO 18:18:55 The implementation is basically done, but the integration and inclusion with legacy wallet code is a bit trickier. I predict integration to be ready for review by EoY 18:19:41 Which should be before FCMP++ hard fork activation 18:19:51 Carrot can be implemented prior to review if we assume review will pass, but we need review prior to deployment. 18:20:11 We also need review done 1-2 months before we ship it for deployment in case more work is needed. 18:20:36 So ideally by EOY but arguably as late as February. 18:20:37 I support a CCS now if jeffro is ready now. 18:21:22 "a CCS now" You mean a contract with a firm, now, right? We don't need a separate CCS, right? 18:21:33 (CCS = Community Crowdfunding System) 18:22:27 I think probably we can decide on this at next week's meeting. A lot of things to consider, but interested people should be able to consider them before next meeting IMHO. 18:22:30 By the way Diego Salazar, ben_sepanski, Alp Bassa LunaZellic lyanaqb , @LindsayTOB, feel free to leave whenever, or stay as long as you'd like. Thank you all for your consideration and patience! All of you are excellent candidates and we are lucky to have your time. 18:23:05 Thank you, jeffro256! Will commercials / price be discussed here or will that be a topic of separate discussion? 18:24:07 Concrete prices won't be discussed in this meeting, except amongst a few members or with explicit approval from you 18:24:22 Quarkslab Team was very happy to present our proposal! Great end of session and talk soon ! 18:24:39 Thank you lyanaqb and QuarksLabs! 18:25:36