<r​ucknium:monero.social> MRL meeting in this room in two hours.

<k​ayabanerve:matrix.org> repo.getmonero.org/monero-project/c…als/-/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.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1086

<r​ucknium:monero.social> 1) Greetings

Hello

<s​gp_:monero.social> Hello

Hello

<l​yanaqb:matrix.org> hello

<j​effro256:monero.social> howdy

<k​ayabanerve:matrix.org> 👋

<j​berman:monero.social> *waves*

Hello!

hi everyone!

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<r​ucknium:monero.social> me: Analyzing node p2p logs, especially transaction broadcast timings. Mostly, things work the way that the code is supposed to work.

<j​effro256:monero.social> 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

<r​ucknium:monero.social> We can go directly into the FCMP++/Carrot agenda item, since I think some people in the room are waiting on that.

<r​ucknium:monero.social> 3) Research Pre-Seraphis Full-Chain Membership Proofs. Reviews for Carrot. getmonero.org/2024/04/27/fcmps.html github.com/jeffro256/carrot/blob/master/carrot.md

<j​berman:monero.social> 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

Hey all, Luna from Zellic here

<r​ucknium:monero.social> Before the meeting, kayabaNerve posted a summary of work that has been accomplished on FCMP++ research and review: repo.getmonero.org/monero-project/c…als/-/merge_requests/449#note_26540

<r​ucknium:monero.social> Thanks, kayaba

<r​ucknium:monero.social> 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?

<j​effro256:monero.social> I believe that kayabanerve had some details to share about his FCMP work before discussion of the Carrot audit

<d​iego:cypherstack.com> hi

<d​iego:cypherstack.com> apologies for being late

<r​ucknium:monero.social> I see . Ok thanks

<k​ayabanerve:matrix.org> Hello, sorry.

<k​ayabanerve:matrix.org> I am here, I just had to step back for a moment.

Welcome back :D

<k​ayabanerve:matrix.org> I would like to go over the FCMP++ Research summary and how that's moving forward, if amenable.

<j​effro256:monero.social> Of course

<k​ayabanerve:matrix.org> 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.

<j​effro256:monero.social> @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

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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.

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

violate the normal existential forgery considerations of address/signature schemes

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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.

<r​ucknium:monero.social> kayabanerve: I'm ok with that, but what is the contingency plan if the attempt to repair the proof fails?

<k​ayabanerve:matrix.org> 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.

<j​effro256:monero.social> I'm also fine with that, but would we also have another player (maybe CS again) review the new security proofs afterwards?

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?

<k​ayabanerve:matrix.org> Rucknium: The proofs should work out. The main concern is if they work out with ideal performance.

<k​ayabanerve:matrix.org> Without divisors, a scalarmul is 512 multiplicative constraints with a reusable prior 256 multiplicative constraint bit decomposition.

<j​effro256:monero.social> LunaZellic: type out the username in the chat and I'll invite you. Sorry we've been having spam issues recently

ephemeral2:matrix.org, thank you!

<k​ayabanerve:matrix.org> With divisors, and no need for a bit constraining, it's 7. 1/110th the constraints.

<e​phemeral2:matrix.org> Thank you!

<a​lpbassa:matrix.org> No worries, I agree that a more incremental approach would be meaningful!

<j​effro256:monero.social> Of course! Sorry about the friction

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> (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)

<r​ucknium:monero.social> Do you have an estimate for what percentage larger that falback would make the input proof/tx?

<k​ayabanerve:matrix.org> 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.

<a​lpbassa:matrix.org> 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).

<k​ayabanerve:matrix.org> 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?

<r​ucknium:monero.social> 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?

At least I see nothing that speaks against it ...

<k​ayabanerve:matrix.org> 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.

<j​effro256:monero.social> And Veridise doing it makes sense here obv since they freshly worked on it. Just for fun, who noticed the issue initially?

<j​berman:monero.social> I +1 this approach as well

<r​ucknium:monero.social> I see. Thank you. So many meanings of "size" ;)

<k​ayabanerve:matrix.org> Alp, thank you for expressing your support for this timeline (which you're only just now hearing of 😅) and iterating your confidence :)

<k​ayabanerve:matrix.org> jeffro256: Alp noted the issue in the few hours of R1CS review already done.

<k​ayabanerve:matrix.org> 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.

<r​ucknium:monero.social> We already had some support for incremental extension of around this budget at a previous meeting IIRC.

<k​ayabanerve:matrix.org> 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.

<r​ucknium:monero.social> 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.")

<r​ucknium:monero.social> Thanks, guests, for your patience :)

<e​phemeral2:matrix.org> No, thank you!

<j​effro256:monero.social> 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

<e​phemeral2:matrix.org> Okay!

<j​effro256:monero.social> Thanks for your patience

<j​effro256:monero.social> Luna, would you like to go?

<e​phemeral2:matrix.org> 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.

<e​phemeral2:matrix.org> (still typing)

<v​tnerd:monero.social> Forgot to today was Wed, sorry I'm late

<r​ucknium:monero.social> jeffro256: Do we have a formal statement of the scope of work? Sorry if I missed it.

<e​phemeral2:matrix.org> 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<clipped message>

<e​phemeral2:matrix.org> that we reported and got fixed (CVE-2024-45039, CVE-2024-45040)

<e​phemeral2:matrix.org> Our audit of Singularity: reports.zellic.io/publications/singularity

<e​phemeral2:matrix.org> PDF: github.com/Zellic/publications/blob…y%20-%20Zellic%20Audit%20Report.pdf

<e​phemeral2:matrix.org> Penumbra audit: github.com/Zellic/publications/blob…a%20-%20Zellic%20Audit%20Report.pdf

<j​effro256:monero.social> Yes scope of worked for the Carrot audit is this document: 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.

<e​phemeral2:matrix.org> 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.

<e​phemeral2:matrix.org> 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!

<e​phemeral2:matrix.org> so I have an emotional connection to this proposal myself haha

<s​gp_:monero.social> Nice to meet you Luna!

<e​phemeral2:matrix.org> 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.

<e​phemeral2:matrix.org> 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!

<e​phemeral2:matrix.org> </spiel done>

<e​phemeral2:matrix.org> Thanks sgp_!

<j​effro256:monero.social> Thanks, Luna! Anyone have any questions for Luna / Zellic ?

<e​phemeral2:matrix.org> \</spiel>

<e​phemeral2:matrix.org> Thanks sgp\_!

<e​phemeral2:matrix.org> (Also, here is the link to the report for the issues we found with Gnark: zellic.io/blog/gnark-bug-groth16-commitments)

<e​phemeral2:matrix.org> I wanted to ask, have the members of the MRL already seen our proposal or is it mainly just jeffro256 so far?

<r​ucknium:monero.social> 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?

<e​phemeral2:matrix.org> It will be Malte Leip, the author of the Gnark advisory linked above.

<r​ucknium:monero.social> person(s)

<e​phemeral2:matrix.org> The second peer reviewer will be Mohit Sharma.

<j​effro256:monero.social> 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.

<j​effro256:monero.social> Okay, if there aren't any more questions, would QuarksLabs like to jump in?

<l​yanaqb:matrix.org> Hi all, Quarkslab team is here ! We prepared a text to outline our offer

<l​yanaqb:matrix.org> # Why us

<l​yanaqb:matrix.org> 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.

<l​yanaqb:matrix.org> dblp.org/pid/44/1487.html

<l​yanaqb:matrix.org> dblp.org/pid/214/8633.html

<l​yanaqb:matrix.org> dblp.org/pid/177/2271.html

<l​yanaqb:matrix.org> # References

<l​yanaqb:matrix.org> - github.com/tari-project/bulletproof…ain/docs/quarkslab-audit/report.pdf

<l​yanaqb:matrix.org> - blog.quarkslab.com/resources/2021-12-08_litecoin/21-08-872-REP.pdf

<l​yanaqb:matrix.org> - blog.quarkslab.com/audit-of-the-mim…le-integration-inside-litecoin.html

<l​yanaqb:matrix.org> # Audit Methodology Proposed

<l​yanaqb:matrix.org> ## Discovery (3d)

<l​yanaqb:matrix.org> 3 days of discovery of:

<l​yanaqb:matrix.org> - Adversary model for each proof

<l​yanaqb:matrix.org> - Carrot construction

<l​yanaqb:matrix.org> - Curve trees

<l​yanaqb:matrix.org> - SoA: Original scheme + subaddress

<l​yanaqb:matrix.org> - Janus attack (and other existing ones)

<l​yanaqb:matrix.org> ## Proofs (~15d)

<l​yanaqb:matrix.org> - Balance Recovery (~6d)

<l​yanaqb:matrix.org> - Unlinkability (~2.5d)

<l​yanaqb:matrix.org> # Timing

<l​yanaqb:matrix.org> End November / December to start and execute is ok for us

<l​yanaqb:matrix.org> Available for questions !

<j​effro256:monero.social> Thank you, lyanaqb

<j​effro256:monero.social> Does Cypherstack want to hop in?

<s​gp_:monero.social> Yes, thank you!

<d​iego:cypherstack.com> We'll do the work. In exchange for Monero.

<j​effro256:monero.social> Let me know if I'm moving too fast, by the way, I just want to make sure to respect the guests' time

<d​iego:cypherstack.com> Brandon Goodell is with us now (surae), and we're on-boarding three more cryptographers that will be reviewing the work as well.

<r​ucknium:monero.social> 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?

<d​iego:cypherstack.com> 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.

:)

<l​yanaqb:matrix.org> It will be one of the 3 Phd and an other one will be the reviewer for the quality process.

<l​yanaqb:matrix.org> It will be one of the 3 PhD and an other one will be the reviewer for the quality process.

<j​effro256:monero.social> Diego, thanks for the input. Following up on timing information, is the turnaround time still estimated to be 3-4 months?

<d​iego:cypherstack.com> I'm also happy to take further questions.

<d​iego:cypherstack.com> 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.

<d​iego:cypherstack.com> 3 weeks more likely.

<j​effro256:monero.social> Alright, good to hear.

<j​effro256:monero.social> Guests from Trail of Bits here?

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.

I’m joined by Tjaden, a senior security engineer on our cryptography team, as well as Chris, our principal sales engineer.

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!

Please see notable similar reviews include: - Zcash: github.com/trailofbits/publications/blob/master/reviews/Zcash.pdf -Stealth addresses: github.com/trailofbits/publications…stealthaddresses-securityreview.pdf (Stealth address scheme for ethereum-based privacy coin - found a number of de-anonymization issues.

Public examples of our cryptographic design reviews to see work and deliverable we’ll produce include: -Discord github.com/trailofbits/publications…cord-dave-protocol-designreview.pdf Ockam: github.com/trailofbits/publications…iews/2023-11-ockam-designreview.pdf

Happy to answer any questions!

<s​gp_:monero.social> Nice to see you again Lindsay (Justin from MAGIC Grants here). Thanks for your proposal

We're glad to be here, Justin - great to be in touch again!

The field of companies doing such reviews seems to be bigger than I would have estimated, interesting

<r​ucknium:monero.social> Lindsay, do you have an idea of who in your company may be the lead(s) on a review of Carrot?

<e​phemeral2:matrix.org> I was assuming everyone had copies or summaries of the proposals; should I share our timeline / availability info here for convenience?

<e​phemeral2:matrix.org> 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.

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

<j​effro256:monero.social> Yes, feel free to attach any info that you would like to share more openly!

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> Thanks, Lindsay

<j​effro256:monero.social> Note that this room is not normally invite-only as has publicly available logs

<j​effro256:monero.social> Note that this room is not normally invite-only and has publicly available logs

<r​ucknium:monero.social> Yes this room is logged: libera.monerologs.net/monero-research-lab

<j​effro256:monero.social> This should've been mentioned in the emails / Slack chats but it probably good to reiterate

<j​effro256:monero.social> And yes, thank you, Lindsay. Finally, I welcome Ben and Alp from Veridise to join in at the moment if desired.

<b​en_sepanski:matrix.org> Hi all! My name is Ben, I am the CSO at Veridise

<b​en_sepanski:matrix.org> 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<clipped messag

<b​en_sepanski:matrix.org> 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

<r​ucknium:monero.social> 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 :)

<b​en_sepanski:matrix.org> 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<clipped messag

<b​en_sepanski:matrix.org> 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<clipped messag

<b​en_sepanski:matrix.org> specially those requiring a deep understanding of mathematics and cryptography.

<b​en_sepanski:matrix.org> 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

<b​en_sepanski:matrix.org> 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

<r​ucknium:monero.social> I should say "community input and scrutiny"

<d​iego:cypherstack.com> all of you smarties should join forces with us and we can make an ultra super mega powerful privacy protocol :D

<r​ucknium:monero.social> Ah, but competition is good. Diego wanting to form a monopoly :P

<s​yntheticbird:monero.social> *smarties* are candy.

<d​iego:cypherstack.com> I meant for Monero >:(

<e​phemeral2:matrix.org> Ack. Zellic:

<e​phemeral2:matrix.org> - Work will be conducted over a 4 calendar-week period

<e​phemeral2:matrix.org> - Availability starts around the beginning of November, to the beginning of December at the latest

<e​phemeral2:matrix.org> - 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.

<e​phemeral2:matrix.org> 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.

<e​phemeral2:matrix.org> 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.

<e​phemeral2:matrix.org> 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

<r​ucknium:monero.social> 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.

<e​phemeral2:matrix.org> (our understanding is that this is essentially being funded by community members and not a foundation of sorts, so cost saving is important)

<j​effro256:monero.social> So many wonderful people here. Thank you for attending and for your input ;). Any technical questions for specific guests?

<r​ucknium:monero.social> In other words, how urgent is Carrot review?

<r​ucknium:monero.social> Does kayabanerve have any questions?

<j​effro256:monero.social> 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<clipped messag

<j​effro256:monero.social> s for a few months IMO

<j​effro256:monero.social> 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

<j​effro256:monero.social> Which should be before FCMP++ hard fork activation

<k​ayabanerve:matrix.org> Carrot can be implemented prior to review if we assume review will pass, but we need review prior to deployment.

<k​ayabanerve:matrix.org> We also need review done 1-2 months before we ship it for deployment in case more work is needed.

<k​ayabanerve:matrix.org> So ideally by EOY but arguably as late as February.

<k​ayabanerve:matrix.org> I support a CCS now if jeffro is ready now.

<r​ucknium:monero.social> "a CCS now" You mean a contract with a firm, now, right? We don't need a separate CCS, right?

<r​ucknium:monero.social> (CCS = Community Crowdfunding System)

<r​ucknium:monero.social> 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.

<j​effro256:monero.social> 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.

<e​phemeral2:matrix.org> Thank you, jeffro256! Will commercials / price be discussed here or will that be a topic of separate discussion?

<j​effro256:monero.social> Concrete prices won't be discussed in this meeting, except amongst a few members or with explicit approval from you

<l​yanaqb:matrix.org> Quarkslab Team was very happy to present our proposal! Great end of session and talk soon !

<j​effro256:monero.social> Thank you lyanaqb and QuarksLabs!

<j​berman:monero.social> Thank you all, excellent candidates

<d​iego:cypherstack.com> We at CS have a separate thing from all of this as an add-on item to the agenda for whenever this one is done.

<e​phemeral2:matrix.org> All right. Thank you very much for the opportunity to present. It was a great meeting that was exceptionally well-run, and talk again soon!

Thanks again for having us! Trail of Bits is excited and eager to work with Monero to help the security of Carrot!

<r​ucknium:monero.social> Diego Salazar: At this meeting? You can bring it up now.

<j​effro256:monero.social> Rather, I should say, concrete prices won't be discussed in the meeting, period. It will be discussed outside this meeting, unless you explicitly give consent to share *within* this meeting

<d​iego:cypherstack.com> Neat.

<j​effro256:monero.social> Thank you, Luna and Lindsay! Have a great day

<a​lpbassa:matrix.org> Thank you! Was nice meeting everyone. Have a nice meeting.

<b​en_sepanski:matrix.org> Thanks all!

<s​yntheticbird:monero.social> Who exactly that is part of MRL will lead the price negotiation off-meeting?

<d​iego:cypherstack.com> In the next couple of weeks we at Cypher Stack will be releasing a paper on churning. It's obviously Monero-focused, but it applies to any small-anonymity set coins. The paper is pretty extensive. In conjunction, we've released a Monero churn tool. github.com/cypherstack/moneromixer

Thank you all!

<d​iego:cypherstack.com> We'll also be releasing the code for how we ran simulations for part of the churn paper.

MoneroMixer is a cool name, but will probably rise quite a few eyebrows :)

<d​iego:cypherstack.com> Monero Butter Maker

<d​iego:cypherstack.com> will change name

<d​iego:cypherstack.com> you know...cuz you churn butter

<d​iego:cypherstack.com> I'm here all week, folks

<s​yntheticbird:monero.social> I almost laughed. almost

<r​ucknium:monero.social> Very interesting. Looking forward to reading it

<d​iego:cypherstack.com> Not even a slight exhale from the nose?

<d​iego:cypherstack.com> Yeah it was a preannouncement, I guess.

<s​yntheticbird:monero.social> i did

Interesting that it did take until now until somebody sat down and built something like that.

<d​iego:cypherstack.com> Slight spoiler: churns are only somewhat helpful

<d​iego:cypherstack.com> but I think that's been suspected for some time

<r​ucknium:monero.social> AFAIK, a churner has been built at least twice before now.

<r​ucknium:monero.social> But with no theoretical backing

<d​iego:cypherstack.com> But with FCMPs right around the corner hopefully it won't matter that much

<j​effro256:monero.social> I'm open to sharing it with people that have been in the MRL a while, I just don't want to leak financial details to the public in an *easily-accessible* way

But maybe with a less solid, well, scientific basis?

<d​iego:cypherstack.com> but, not to dog on you guys on MRL, work can sometimes go slow, and work can sometimes go fast.

<j​effro256:monero.social> yeppp

<d​iego:cypherstack.com> So since the exact release time of FCMPs is unknown, we thought it'd be good to have some things available to the public while we wait for the FCMP goodness

<s​yntheticbird:monero.social> Can I assist to the negotiation? I haven't contributed in the MRL but I'm highly interested into learning the process.

<d​iego:cypherstack.com> Because, all of our findings on the usefulness of churn go out the window with FCMPs. As in, the tests and heuristics that would apply to current Monero don't apply after FCMPs go live. Which is kind of a 'no duh, that's why we're moving over' thing, I guess. :P

Will negotiations proceed with all companies until a definite offer is on the table, or will the field get narrowed down first?

<k​ayabanerve:matrix.org> Rucknium: No, a CCS. The Research CCS isn't scoped to Carrot.

<r​ucknium:monero.social> Ok. That changes the timeline

<k​ayabanerve:matrix.org> Even if there wasn't that procedural issue, I was not involved with the Carrot process and would need to be cc'd on and review those discussions to personally endorse. There's also some question of how much that stretches the Research CCS since it's 25% done (good) but we haven't started audits (bad).

<j​effro256:monero.social> rbrunner: that's a good question. I think we can narrow it down some first

<d​iego:cypherstack.com> Given that I gave my price in Monero, you guys would be getting a steal now :D

<j​effro256:monero.social> I don't know if there will be "negotiations" in the sense that we try to advocate for a lower price based on the offers of others, but we'll see

<s​yntheticbird:monero.social> understood

<r​ucknium:monero.social> Technically there are two more agenda items, (1) Stressnet and (2) The 10 block lock. AFAIK, there is not much to discuss about stressnet (except my spamming wallets ran out of money and I needed to replenish them). On the ten block lock, I don't plan to do more research on it in the short term. Maybe someone else has something to discuss on those items.

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone!

<j​effro256:monero.social> To follow up on previous discussions about including Janus resistance in the scope of properties for which we want security proofs, I advocate that we do include it. The difference in quotes to include Janus resistance was 25%-33%, which is reasonable. Also, I've had a few people ask me about Janus attacks and my general feeling is that the general Monero audience doesn't yet enti<clipped messag

<j​effro256:monero.social> rely understand how Janus attacks works, which makes user-side mitigations hard. This should be an argument in favor of prioritizing it IMO

<j​effro256:monero.social> Yes, given that the XMR/fiat price has had some pretty substantial action, would you like to amend the quoted XMR price before a formal decision?

<d​iego:cypherstack.com> What'd I quote? 125?

<d​iego:cypherstack.com> Sure. Updated quote to 126 XMR.

<j​effro256:monero.social> Duly noted :)

<k​ayabanerve:matrix.org> Oh. I had a brief dev update. I believe I've finished making divisors constant time. boog900: really helped with the complexity of one segment. I do believe I have better benchmarks on the topic now.

<j​effro256:monero.social> Does anyone have any observations about specific auditors based on the information provided by the guests, pros or cons?

<k​ayabanerve:matrix.org> I'm now continuing work on cleaning the dataflow of the proof (not the internal gadgets/functions) to make that proper. Then I'll add support for the multi-input case (within a single proof).

<j​effro256:monero.social> Awesome! Great to hear

<k​ayabanerve:matrix.org> I'd appreciate and advocate for Janus inclusion in Carrot.

<r​ucknium:monero.social> I liked when firms gave specific relevant examples of past work.

<s​yntheticbird:monero.social> when I see some of them I kneel.

<s​yntheticbird:monero.social> when I see some of them I kneel 🧎‍♂️

<r​ucknium:monero.social> I am thinking about firms that have already participated in FCMP++ review vs. those that have not. It is "good" when a firm already knows FCMP++ because they can apply what they know. It is "good" when a firm has not looked at FCMP++ yet since they could spot something with fresh eyes that previous reviewers missed.

<s​yntheticbird:monero.social> I guess we can't take two of them at the same time? not enough money ?

<j​effro256:monero.social> If it makes sense, we *could* do what we did with FCMP++: have one firm create proofs and the other review the proofs

<j​effro256:monero.social> Is it overkill for Carrot which bears many similarities to the current addressing protocol and for which we also need implementation reviews? Maybe, maybe not

<j​effro256:monero.social> Does anyone *object* to including a security proof for Janus resistance for up to 33% higher review costs?

<j​effro256:monero.social> This is a thought that I have had too...

<j​berman:monero.social> Not from me, it's worth that cost imo. the Janus attack is a pretty significant knock on subaddresses

Not me. We should do it right. We will probably live years with this addressing scheme.

<r​ucknium:monero.social> Janus resistance proof sounds good to me :)

<k​ayabanerve:matrix.org> I don't think FCMP++ prior matters.

I feel with syntheticbird. It's somehow breathtaking how big the field of cryptography has become in the wake of cryptocurrencies, smart contracts and such.

<k​ayabanerve:matrix.org> Re: Carrot, we have address of a form (S, V) or (S_i, V_i) and need to generate a one-time key of O.

<j​effro256:monero.social> I tend to agree with kayabanerve , but there are *sometimes* when the leaky abstraction of FCMP++ as presented in the Carrot spec *can* matter. For example, the privacy of collaborative transaction building in a Carrot-compatible way can be affected by how Bulletproofs are batched on the outputs

<k​ayabanerve:matrix.org> BP structure is out of scope to Carrot

<k​ayabanerve:matrix.org> So is the FCMP and GSP

<k​ayabanerve:matrix.org> All that matters to Carrot is generation of an O whose x/y components are unknown to the deriver.

<k​ayabanerve:matrix.org> (and is known to whoever has the dlogs for an address, and that the independent claims of Carrot are correct)

<j​effro256:monero.social> But it still affects it somewhat. Since BPs+ are batched, the prover needs to know all amount commitments openings. If there was one BP+ per output, then there might be the possibility of doing collaborative transactions without knowing the amounts of the counterparties.

<k​ayabanerve:matrix.org> Hm. It's a bit muddled due to F-S requirements but we should still be able to create a properly modular definition for the bounds expected by an addressing scheme.

<k​ayabanerve:matrix.org> jeffro256: What in Carrot changes on this premise?

<k​ayabanerve:matrix.org> Carrot is not a collaborative TX protocol and Carrot does detail communication of the commitment mask, but does not involve creating TXs at all per my view.

<j​effro256:monero.social> Nothing written down in the spec currently, I'm just saying that it could have an affect on future applications

<k​ayabanerve:matrix.org> It reads to me as if you're applying the role of Carrot to the sender when I'd argue it's primarily about the receiver.

<k​ayabanerve:matrix.org> I fundamentally don't understand the point you're trying to raise so I'll drop it.

<j​effro256:monero.social> As it pertains to the review as-is, prior FCMP++ knowledge probably isn't crucial

<k​ayabanerve:matrix.org> Oh. That was the other thing. Veridise has worked on a component of the circuit. they haven't worked on the composition nor the entire circuit.

<k​ayabanerve:matrix.org> We have a work history we can evaluate based off of. I wouldn't credit them a history on FCMP++s as relevant to this discussion.

<j​effro256:monero.social> It's not super important so you don't have to worry about it until I think about how to reword it and bug you again ;)

<j​effro256:monero.social> Yeah I think it's pretty uncontroversial to say that divisor work won't really be applicable to Carrot

<j​effro256:monero.social> FCMP++ composition is the only thing somewhat directly applicable

<k​ayabanerve:matrix.org> While uncontroversial, I'm unsure some people understand that distinction, hence why I wanted to explicitly state it.

<j​effro256:monero.social> Didn't Cypherstack write an alternate addressing scheme for Monero which provided return addreses?

<r​ucknium:monero.social> Salvium?

<r​ucknium:monero.social> Diego Salazar: Do you want me to review the churning paper so that you can remove the "not peer reviewed" notice from your paper template? :D

<d​iego:cypherstack.com> oooooooh

<r​ucknium:monero.social> Not a double-blind review of course, but something

<j​effro256:monero.social> Yes, that was what I was thinking of. However, it looks like old contributor knacc was the one who wrote it?

<j​effro256:monero.social> Okay, well it's getting pretty far over. Do we want to make a decision next meeting to give some time to review details?

<r​ucknium:monero.social> I think a decision could potentially be made next meeting.

<j​effro256:monero.social> I've got to dip out, but thank you everyone for letting me take up such a large chunk of your time! The feedback was very helpful, and I look forward to perhaps making a decision soon

re: > <rbrunner>: MoneroMixer is a cool name, but will probably rise quite a few eyebrows :) -- sorry about that, I picked the name and have had moneromixer.com for years as a joke, suggest replacements freely haha