15:49:31 MRL meeting in this room in about one hour. 15:50:03 kayabanerve: ^ Remind of the meeting at 17:00 UTC today 15:50:25 I am aware :) Thank you 15:50:27 also kayaba if you see this, please answer jeffro in lounge 15:50:37 FYI, the github issue says the 3rd. I noticed when I checked it for the time :p 15:50:46 Oh. Thanks 15:51:15 Fixed :) 16:22:18 reputational harm didn't stop Veridise from rushing their work, producing questionable proofs and not noting the core problems with Eagen's work 16:59:36 Hey guys. I'm a stupid. 16:59:44 Its not 70 XMR. Its 175. 16:59:54 https://libera.monerologs.net/monero-research-lab/20250402#c515638 17:00:01 https://gist.github.com/kayabaNerve/3a32eb393a41f48fe7c183c31dc57680 17:00:20 🤏 almost 17:00:39 Meeting time! https://github.com/monero-project/meta/issues/1217 17:00:45 1) Greetings 17:00:50 Hi 17:00:53 hello 17:00:54 Hi 17:01:03 *waves* 17:01:06 We have been greeted by a larger bill :D 17:01:07 Hi 17:01:09 hello 17:01:18 <0xfffc:monero.social> hi everyone 17:01:23 Hello 17:01:30 👋 17:01:31 A deserved one neitherless 17:01:56 Hi 17:02:52 Howdy 17:03:12 2) Updates. What is everyone working on? 17:03:37 I could make a PR, ready for review, for the improved peer selection with less connections to spy nodes: https://github.com/monero-project/monero/pull/9939 17:04:13 me: Pushed draft version 0.3 of the MRL research bulletin on subnet deduplication to reduce spy node effectiveness: https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/monero-peer-subnet-deduplication.pdf . boog900 is reviewing it and once done, will be added as a co-author. Also working on our/my MoneroKon presentations. 17:05:03 I am working on the scaling for FCMP+ The consensus part is done. The fees node relay part I expect to have next week. 17:05:11 me: continuing on FCMP++ / Carrot tests, ran into some snags / identified things to fix in wallet behavior 17:05:30 Finally making some real progress on HW device stuff and hot/cold stuff now that I've gotten the major carrot_impl rework out of the way. Also been trying a bit to debug issues that people have sent in 17:06:33 Auditing my own finances apparently. 17:06:40 <0xfffc:monero.social> Addressing the PR comments. Have been off for few days. Will be part time for a few days more. I have already decided and sketched out what to do about the comments. I just have to wrote the code. 17:08:07 Me: looking at LWS stuff: why /get_random_outs was crashing on osx, and LWS push/truncated tx history stuff 17:08:36 0xfffc: The PR you are referring to is the more efficient tx propagation implementation, right? 17:08:52 <0xfffc:monero.social> Yes 17:08:58 Fixing eagen's calculus mistakes 17:09:04 <0xfffc:monero.social> https://github.com/monero-project/monero/pull/9933 17:09:16 3) zkSecurity quote for review of Elliptic Curve Divisors for FCMP in parallel to Cypher Stack review. https://hackmd.io/@rotn/HyyFGZcfxl https://github.com/cypherstack/divisor_deep_dive 17:10:05 surae: Maybe I could take a look at the calculus. Probably I would be little help, but there is a small chance. 17:10:17 My comment from a day ago is still my primary response to immediate questions. 17:10:37 Hey all, I believe that this SoW for a third reviewer of divisors is in the best interest of the Monero community. I would ideally like to get preliminary approval to pursue this contract 17:10:52 This one? 17:10:53 > zkSecurity is underestimating, has lower standards, see something not prior seen, or truly just have a domain expert. I'll note the divisors technique, without proofs, has been incorporated into a major paper by cryptographers who presumably believe it tracks. Obviously, the issue is the security proofs, but as zkSecurity's estimate is non-binding, payment is an acceptable flat rate, and the seemingly worst case is we get another set of security proofs CS still doesn't find up to standards, I'm in favor. 17:10:58 Pretty sure we landed on the correct verification equations but more review is better 17:11:10 Cypher Stack staff should feel free to comment on this issue 17:12:27 This project will aim to remove blockers preventing Monero from using the more efficient divisors technique. As stated in the SoW, it is fixed rate and requires sufficient proof to be delivered. I will work out the final payment details and any other suggested SoW modifications based on the feedback provided during this meeting and prior to this meeting 17:13:04 Where would the funds come from for the zkSecurity work? 17:13:21 I am asking for a donation from the research CCS 17:13:47 More review is better. I am not familiar with the current proposal for review on the table so I can't speak about it. If the reviewers at zksecurity are trustworthy and competent then great. It would be a shame to spend money on people who regurgitate substandard previous work though. 17:14:07 Yes, Rucknium 17:14:09 Here's a list of what has to be funded with the remaining FCMP research CCS funds: https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/ 17:14:22 the reviewers are Mathias Hall-Andersen and Diego Aranha 17:15:03 MHA is a coauthor of curve trees. 17:15:09 AFAIK, the FCMP research CCS has 897 XMR remaining. 17:15:19 These items have a combined cost of 75,000 USD: Gadgets formal verification, Gadgets impl audit, Circuit impl audit 17:15:23 I also confirm 897 17:15:34 after CS is paid the 175 17:15:45 By my calculations, 897 XMR (currently valued at ~$294 000). https://cryptpad.fr/sheet/#/2/sheet/view/7aKf7Z2rxNnMLJhx2cvkPH8nMbJcHilMoz3vKf+Q+oQ/embed/ 17:15:52 Note that remaining funds tally currently doesn't include the 175xmr to CS. Expected balance is 897.13 including that 17:16:09 These don't have an estimated cost yet, AFAIK: GSP impl audit, EC Divisors impl audit, Towering curve cycle audit 17:16:34 ^ AFAIK, those are code audits, not mathematical reviews of the cryptographic soundness of the protocol. 17:16:47 according to my notes, EC divisors is the same as towering curve cycle 17:17:13 Presumably we may also have non-divisors reviewed academically (?) and audited 17:18:32 Veridise gadgets/circuits should be shared this week (if not today) 17:19:17 The zkSecurity quote is 50,000 USD for one week of work by two researchers. Previously, proposed work by zkSecurity to formalize Seraphis was 10,000 USD per week of work (presumably by one person): https://libera.monerologs.net/monero-research-lab/20230927#c284121 17:19:30 We have the gadgets verification, impl audit, and circuit audit under our last quote with Veridise. 17:19:33 cc SGP_ if MAGIC has drawn those XMR yet. 17:19:45 MAGIC has received that donation already 17:20:00 fwiw guys, our divisors work is going pretty smoothly. It's a lot of work, but we're making good time. 17:20:17 is it possible to get them to agree to a partial payment upfront sgp_ ? so they have an incentive to put in the extra mile? 17:20:26 EC divisors lib audit and towering curve cycle lib audit are two items, but both had optimized impls scoped into the contest with audits scheduled for those optimized impls 17:20:33 I wanted to be done today but alas 17:20:37 I will specifically propose 50-50 payment for zkSecurity 17:20:48 In that case, Rucknium, those items had a combined cost. 17:20:54 surae blink twice if you are held hostage 17:21:17 This is what does somehow not square for me, as already ranted yesterady: How zkSecurity can propose 2 person weeks for something Cypher Stack already spent many weeks on, and is not yet finished 17:21:50 I know when valued at a weekly rate, $50k is a lot. But so long as the understanding is that they truly will ensure that we will get a fully finished deliverable that meets our requirements, then $50k is worth it imo 17:21:52 surae: Diego Salazar Maybe you don't want to say quite yet, but is the divisors work going in the direction of "it is sound", or in the direction of "it is unsound"? 17:21:53 sgp: Towering curve cycle refers to the Helios/Selene pair of curves that we use, plus the technique which allows our curve, ed25519, to plug into that cycle. EC divisiors is a technique under review for FCMPs which is more-or-less "internal" to the membership proof. Even if we don't use divisors, we will always need a curve cycle for FCMPs 17:23:19 Sound. 17:23:31 Hm, if CS is close to producing another divisors deliverable, perhaps it makes sense to hold on zkSecurity until that deliverable 17:23:33 Yeah 17:23:41 If things take a terrible turn for the worse, you all would be the first to know pretty quick. 17:23:49 Except 17:23:53 There are mistakes 17:24:12 Hello yes I would like 50k for one week of work, thank you 17:24:14 The correct verification equations we have derived already 17:24:15 So you will write new proofs and those proofs have to be reviewed by yet another firm, probably 17:24:26 I did check with surae regarding proximity and they did not recommend delaying the zkSecurity quote, and here encouraged more review. 17:24:37 Okay so let me explain a little bit more in detail 17:25:01 @rbrunner some people underestimate their time so they can claim that their rates are high. So "1 week = 50k = our rate, even if its really 4 weeks. At best, we make 50k in a week. at worst, we can tell people that our going rate is 50k/week" 17:25:08 Does the protocol need to be altered, a little, to make it sound? 17:25:13 Freeman: please email hello⊙cc and I'm sure they'll sort you out :) 17:25:18 Sorry if you've already answered this question, sgp, but is there anything specific to your knowledge that ZKSecurity will do differently (or specific expertise) that will result in a different outcome as CS? 17:25:48 https://matrix.monero.social/_matrix/media/v1/download/cypherstack.com/EOuiawmkasyiwspvsykDwbOb 17:26:01 1. The Eagan paper had some calculus mistakes which we have corrected. 17:26:16 2. Due to those mistakes the verification equations implemented by kayaba are not correct 17:26:20 IIRC, at time MRL has had multiple mathematical reviews and/or code audits done by different firms, for the same protocol. 17:26:57 3. Modifying the code to be correct will require further later review. And as kayaba says checking my proofs will also require further review 17:27:13 It is primarily their different way of approaching the problem based on their different experiences 17:27:28 Does this mean that the FCMP competition coders are coding for the wrong target? I wonder how much of an effect that would have. https://www.getmonero.org/2025/04/05/fcmp++-contest.html 17:27:57 Allegedly, until you demonstrate a full proof forgery on a 180 MHz pentium with 8 MB of RAM to prove it's practical /s 17:28:01 Answered by surae. Thanks. 17:28:08 With this in mind, it seems to me like paying for ZK security to review. The current implementation is not necessarily a good usage of funds. I am biased because I work for cypher stack obviously. if the community wants to pay for this, then... 17:28:19 (obviously, I joke, and the version of the equations proven secure will be the ones moved forward with) 17:28:35 Rucknium: No impact if we keep divisors. 17:28:38 If this money is going to be spent anyway, and if I had a perfect world, then I would recommend that these researchers start reviewing what I've been writing 17:28:44 Ig we can rejoice that there are no contester that manage to achieve the contest goal. Otherwise the ethical "should we pay them despite being insecure" question would have arrived 17:28:58 This would land us on a correct protocol faster rather than recreating wheels over and over again with reviews 17:29:02 Helios/Selene will almost certainly remain the same to my knowledge. Divisors won't, however, if we don't go with divisors.. 17:29:41 and the divisors lib included doesn't include the verification equations, hence why "no impact if we keep divisors" 17:30:03 But that library is constructing proofs for the old verification equations 17:30:08 Those proofs won't pass the correct verification equations 17:30:13 So that code will still need to be modified? 17:30:20 So that code will still need to be modified. 17:30:29 Sorry voice to text is killing me today 17:30:39 No, that lib is solely calculating divisors. 17:30:51 SyntheticBird: `Otherwise the ethical "should we pay them despite being insecure" question would have arrived`: IMHO, there is no question. Of course they should be paid because MRL/Core made that promise. The mistake is MRL's fault on going forward without 100% certainty. 17:31:02 Does your modified verification statements still require I calculate a polynomial which I refer to as a divisor? 17:31:12 If yes, then that lib is drop-in regardless. 17:31:26 That was my opinion as well 17:31:31 The formatting for use in a ZK proof, and verification statements, is a separate lib entirely 17:31:55 so compo may not be altered ? 17:32:19 Yes and that interpolation code will not require modification 17:32:46 Right, so this divisors lib in contest scope won't so long as that statement holds true 17:32:56 I didn't realize the extra comps were separated, that's good. That means kayabas witness construction code is fine 17:33:23 The _competition_ won't be altered regardless b/c MRL made a promise. Whether or not the results will turn out useful depends on divisor's academic journey 17:33:33 Yep, one finds the polys, one does the gadget within a ZK proof with the polys. 17:33:44 Fwiw, I solicited this zkSecurity quote because I believed that CS's divisors work was potentially months away from being finished. If this work is expected in the near future, and is compatible with Monero's intended use-case, then I would suggest waiting a week and down-scoping zkSecurity's work to a review of CS's work. But if it keeps getting delayed (it's been delayed many ti 17:33:45 mes, research is hard), I'd rather have a concurrent research effort on this critical blocker (divisors) 17:35:03 it has indeed been delayed many many times as we always thought we were close to completion and then hit bear trap after bear trap 17:35:07 Good foresight 17:35:16 so I can see how our "things are going well and we might be done soon" is....tenuous 17:35:19 As I understand, Cypher Stack is close to "some" result. What more would need to be done to prove divisors secure? What about the commentary that the security depends on choosing specific parameters? How can those be chosen and evaluated? 17:35:39 s/secure/sound 17:36:49 I mean, that's part of the process, once we have all of our proofs written, we can assess practical security for concrete implementations 17:37:12 But I don't want to say much more about that at the moment 17:39:00 I can hold off on the zkSecurity quote until next meeting. But I definitely don't want to delay such a critical component unnecessarily, indefinitely. Worst case we waste some money to make sure this critical component (which is already a blocker!) is addressed more quickly 17:39:20 I think one week's wait is reasonable. 17:39:29 Is cryptography related work really so different from dev work? Imagine I work many weeks to implement something, my boss gets impatient, gives the same work to some other guy who claims to do it in 2 weeks. Does that sound credible? 17:39:45 you have 168 hours 🕐️ 17:39:48 :) 17:40:01 pizzas won't be enough... 17:40:22 This is kind of what we're saying though. What ZKSecurity would be reviewing would be incorrect (since we've already found incorrect things that we've since rectified or been working on rectifying) 17:40:59 I also think waiting a week is reasonable. In the meantime, sgp_ , do you think it would be a good idea to ask zkSecurity, informally, about switching the task to reviewing Cypher Stacks's work? 17:41:15 I second waiting on a week for divisors review. Additional proposal: what if we request zkSecurity do a holistic review on all already completed proofs? Essentially we get another independent party involved reviewing the academia, and that independent party happens to include a co-author of curve trees 17:41:28 So to use your analogy rbrunner, the dev work that takes many weeks to implement is because there was an issue with architecture. The extra time is because the architecture is being tweaked and touched up. The boss gets impatient and gets someone else to do an implementation with the original, flawed architecture. 17:41:30 since their earliest start date is late this month, I'll bring that up next week if applicable 17:41:51 What does holistic review means? 17:42:18 Personally I think this is premature without divisors 17:42:21 Well, maybe it would be best to bring it up with them ASAP because that specific time "slot" won't necessarily be reserved for FCMP work indefinitely 17:42:32 The zkSecurity proposal contains the following point: "Proving any/all potential holes/inaccuracies left by Bassa" 17:43:08 They will probably move all that out of the way on the first or the second day :) 17:43:39 "holistic review" would include a review of all prior proofs, which right now is GBP and FCMP+SA+L composition 17:44:19 Rather optimistic to claim they'll patch ANY/ALL holes, with potentially unbounded pro bono hours, with a timeline of 1 week. Just my two cents. 17:44:36 I find it credible that one of the authors of the curve trees paper can knock the crypto part of this out of the park. I am skeptical someone who didn't teach calculus for 10 years would catch the mistakes we caught. Having said that... 17:44:46 optimistic or they are taking adrenaline shot 17:44:53 More review is better, it's just better to not reinvent wheels 17:45:15 Personally I think we can move on to the next topic; we'll check in next week 17:45:27 Great 17:45:51 More comments or questions on this agenda item? 17:46:16 kthx 17:46:30 jberman: DM me later with what that holistic review would look like, including divisors ideally (if those are done, we can package alltogether) 17:47:27 Reason I bring it up now is because I wouldn't want that author to get assigned / work on some other work and then be unavailable. Even if we decide to delay them on reviewing divisors, I think it's worth bringing up that we do want to engage them 17:47:56 I'll stress to them that we're very interested in keeping the time slot with some work 17:48:53 I got nothing except thank you Cypher Stack <3 17:49:05 I got nothing more on this topic* 17:50:32 4) Subnet deduplication in peer selection algorithm to avoid spy nodes. Draft research bulletin, implementation PR: https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/monero-peer-subnet-deduplication.pdf https://github.com/monero-project/monero/pull/9939 17:50:57 Now we have an implementation ready for review by rbrunner ^ 17:52:11 This triggers two possible events: someone can now review it. And previously we discussed that if such a countermeasure has an implementation, then the method for distinguishing spy nodes, discovered by boog900 , maybe can be published. 17:53:16 Without testing etc, i assume this respects --add-priority/exclusive node and --max-connections-per-ip flags? Rbrunner7 17:53:30 Yes. 17:53:33 Anyone interested in volunteering to review this? 17:54:48 add-priority/exclusive dont effect incoming. Does this only deal with outgoing connections? 17:55:15 Or does it also effect peer evictions 17:55:18 Yes. It is in fact a very narrow, fully drop-in replacement 17:55:34 Just choosing new peers to connect to differently. 17:55:46 Ok thanks 17:55:47 It's a single method that changed 17:57:57 rbrunner: Does this fix the "futile connection attempt" issue you found, or would that be separate? 17:58:17 Yes, it does fix that. That's a small change in a second method. 18:01:09 tobtoht, selsta: Any idea yet when the next Monero release version may be? Just wondering about when may be the timeline for needing to get this and other PRs reviewed in time for next release. 18:02:22 Anytime, master should be stable, just need to iron out the versioning (v19 instead of v0.18) 18:02:34 Like I said in updates, I pushed version 0.3 of my draft MRL research bulletin: "Subnet Deduplication for Monero Node Peer Selection" https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/monero-peer-subnet-deduplication.pdf 18:03:05 Besides content updates, it now has the MRL research bulletin header and formatting. 18:03:15 There havebt been many big recently. Socks5, dynamic bss, some fixes. Txrelay is a bigger one 18:03:33 many big prs* 18:04:28 I don't know if anyone cares about this, but previous MRL bulletin used the [1] citation format. In this draft I use the [Author, Year] format. I prefer the latter format, but if someone prefers MRL keep the old format, I would be willing to change. 18:05:20 And guix stuff, since master gets rid of gitian 18:05:55 I don't know if previous research bulletins had any formal review process. I doubt it. If there was a process, someone let me know. But, anyway, anyone can give feedback on the current draft, of course. 18:07:56 Anyone have comments on this? IIRC, jeffro256 had some views 18:07:57 > And previously we discussed that if such a countermeasure has an implementation, then the method for distinguishing spy nodes, discovered by boog900 , maybe can be published. 18:08:44 no hurry. 18:10:04 Let's move to the final item: 18:10:13 5) Web-of-Trust for node peer selection. 18:10:48 Since I was blocking the publicization of the technique, it makes sense for me to have to review rbrunner's PR 18:11:23 That's one way to see it :) 18:11:24 I wonder if it would be a good idea to implement WoT in cuprate first, to see how it would perform on mainnet 18:12:06 next step may be to agree on data structures and how the old scoring is actually used today 18:12:12 jeffro256: I would support that :) 18:13:20 Cuprate was meant to be testing ground for new features 18:13:54 At least cuprate the code, not sure about the Cuprate/cuprate repository 18:14:35