00:40:05 <321bob321:monero.social> deity twatted about it ? 15:01:52 MRL meeting in this room in two hours. 15:43:35 [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) as of yesterday, there was 1072xmr left in the research ccs 15:44:45 This includes the 70xmr to cypherstack. Sgp has the number at 1002 if including the 70 17:00:14 Meeting time! https://github.com/monero-project/meta/issues/1231 17:00:19 1) Greetings 17:00:26 Hi 17:00:34 Hello 17:00:43 Hi 17:01:46 *waves* 17:01:50 👋 17:02:30 2) Updates. What is everyone working on? 17:03:08 me: Set up a data pipeline and visualizer webapp for the Monero node network scanner. Repo: https://github.com/Rucknium/xmrnetscan Webapp: https://moneronet.info/ (not to be shared on social media yet). Continuing to monitor Qubic's hashpower share. Updated plots here: https://gist.github.com/Rucknium/0873b10b6d36ff6c9d6f8f54107d16f7 17:04:07 Howdy 17:04:18 yo. i finished up the latest draft of silver bullet and sent it along to kayaba. i will be around for a bit to answer any questions which have come up. when we are done copyediting, we will be putting it up on iacr 17:04:41 Me: updated jeffro256 mx255519 fork to support arm64 asm. Updated LWS API specs. Currently working on seeing if I can simplify the lws build process a bit 17:05:31 * the asm now does unclamped calculations correctly 17:05:53 Hello 17:06:07 I am finalizing scaling and fees after MoneroKon 17:06:07 For the most part the current fee structure can remain with FCMP++ 17:06:09 There are some consensus changes to the Medians and transitional changes to accomodate FCMP++ 17:06:26 me: reduced data stored per output in the curve tree, continued PR review, subaddress lookahead expansion 17:07:41 3) [SLVer Bullet: Straight Line Verification for Bulletproofs](https://github.com/cypherstack/silver-bullet). [Cypher Stack review of divisors for FCMP](https://github.com/cypherstack/divisor_deep_dive). 17:09:32 Did kayabanerve complete his review of SLVer Bullet? Where do things stand? 17:10:21 Not quite. I'm still working on mapping it into FCMP++. 17:11:41 surae/Goodell put up a thread about SLVer Bullet on BlueSky: https://bsky.app/profile/bggoodell.bsky.social/post/3lswc55nwhc2j 17:13:54 Anything more to discuss on this item? 17:15:10 4) [FCMP++ optimization coding competition](https://www.getmonero.org/2025/04/05/fcmp++-contest.html). 17:15:48 The submission period for the competition has ended. Any info to share, jberman and jeffro256 ? 17:16:33 We received 2 helioselene submissions, 1 divisors submission 17:17:42 Divisors submission so far looks very solid, pending further review (initial benchmark clocks in at 95%+ speed-up). We may not end up needing a blinds cache 17:18:02 hi, i've started fiddling with shadow, got it to at least run 2 nodes :/ 17:18:14 Holy moly 17:18:27 95%? Wow. How much does this operation account for, out of the whole tx verification? 17:18:33 Will author name be revealed ? 17:18:45 If the author wants yes 17:18:56 this is strictly blinds calculations on the proving side 17:19:00 does not affect verification 17:19:06 Just to be clear - it's almost twice as fast as the code is now? 17:19:25 Oh 17:19:37 Like 30 times as fast 17:19:39 No, 30x. 17:19:44 wow 17:19:48 wow 17:20:16 Ah, I see. A bit strange to express that as "95% speed up", but yeah, wow :) 17:20:22 That means alpha stressnet can get more stressy :D 17:21:07 Only provers benefit, so only sort of? Besides, provers could already cheat this if they wanted to. 17:21:49 I mean, if tx proving took a long time, then it would be hard to send a lot of txs on the stressnet, even with the blinds cache 17:22:30 Unless the prover cheats, which they can. 17:22:54 Are there good news on the verification side? 17:23:28 Well, at least it avoids anyone needing to write "cheating" prover code specifically for the stressnet 17:23:42 (And what is this cheating, anyway?) 17:23:51 Oh, maybe make unspendable outputs? 17:24:37 No. The divisor is used to prove a scalar multiplication. You can take one scalar and make a proof for it. That proof is then always usable for any instance of that scalar. 17:24:56 Scalars shouldn't be reused, as it breaks the privacy of the scheme. If you don't care, you can reuse them however. 17:25:03 On helioselene: we have some thoughts on the submissions. Initial speed-ups clock in in the range of 20-40% as is, but have some issues that jeffro, kayaba and I have been discussing 17:25:15 You can "cheat" by re-using divisors, which is bad for privacy in the real world, but allows you to create valid FCMPs really fast. 17:25:26 I'll get more into helioselene once we're done discussing divisors here 17:25:46 There's also worse things you can do, but that's the trivial way to cheat. 17:26:05 I see. Maybe not a good idea to push that type of "cheating" code out into the wild, then, or someone might use it. Or ChatGPT would use it 😬 17:27:42 Ok going to continue on helioselene 17:28:41 The primary issue with both helioselene submissions is that they replace ed25519 arithmethic, which was not intended scope of the contest and we unfortunately did not explicitly rule it out in the contest rules (I also mistakenly told one contestant it was ok to swap out dalek-ff-group in a DM when they asked i.e. could replace ed25519, and the rules did not explicitly rule it out 17:28:41 ). One submission (the one I DM'd) is still over the 20% floor for validity swapping dalek's ed25519 back in. The other is trickier to swap back in and we don't know right now if it would still meet the bar 17:29:18 I was invited to review the above and fundamentally disagree with that position. 17:30:07 The libraries worked to a purpose and there was a reasonable intent the derivative libraries would work to the purpose. We explicitly included an arbitrary disqualification rule for any libraries which met the rules yet didn't meet the purpose. 17:31:09 Both Helioselene submissions replaced the 2**255-19 field definition used, and in doing so, broke interoperability with the Ed25519 curve library used (where the Helioselene library implements a curve cycle whose entire purpose was interoperability with the Ed25519 curve). 17:31:49 So they work on their own alone, but not within the proposed framework? 17:31:55 While it wasn't explicitly tested, and accordingly wasn't covered under the requirement tests pass, deleting functionality from the codebase is not a legitimate way to claim a faster codebase. 17:32:33 There is the complexity in that jberman personally gave a clarification to a contestant claiming this would be legal, when I would say it absolutely shouldn't be. 17:32:55 They will fundamentally not compile in the FCMP++ codebase and would require changes to the larger codebase. 17:33:42 And they are not that radically faster to make that look worthwhile 17:33:53 With one submission, I was able to revert back to the existing definition without notable complexity. It still met the 20% minimum improvement criteria. It also included variable-time arithmetic and is accordingly invalid under that rule. 17:34:28 With the other submission, I was unable to trivially revert back to the existing definition of Ed25519 due to how the library at large had been reworked. I accordingly cannot comment if it'd still meet the 20% criteria. 17:34:46 kayabanerve: Their original submission had variable-time arithmetic, not your edit? 17:35:32 With those pain points aside, I'll note I'm personally disappointed neither submission implemented the Crandall-prime reduction which was a specific property tevador chose the field bespoke to Helios/Selene to have. 17:36:55 Rucknium: Both libraries replaced the definitions of the representations of the mathematical finite fields. One did so with a bespoke implementation (a rather simple 256-bit representation, optimizing for how the 256th bit is unused as our fields only require 255 bits), and one did so with a distinct off-the-shelf integer representation. 17:37:33 The bespoke implementation is the one which executes in variable time, and the one I was able to revert as required for potential usage in FCMP++. 17:38:21 And having variable-time disqualifies a submission, right? 17:39:24 The one which used a distinct 'off-the-shelf' (it was forked and optimized to some degree my review has yet to cover, apologies for any handwaving there which is dismissive of work) implementation was the one I couldn't make legal for re-benchmarking and I'm unsure if it'd still meet the required performance metric after (as this may halve its performance gains, and it did not gai n twice the required minimum). 17:39:33 Correct, and that was an explicit rule. 17:41:07 So to be a pedantic asshole, even with the exception granted, both of these submissions could be immediately disqualified leaving literally no one happy. While we could reconcile the good parts of the submissions, we'd still need the Crandall-prime reduction and associated bespoke finite field implementation to be optimal. 17:41:25 Yes, technically it is explicitly illegal for the code to be variable time dependent on secret data. Although it can be argued whether or not a submission should be outright denied for variable timeness and the other aforementioned issues if there are other valid parts of the code that are usuable, and fixing those problems would result in the fastest now valid submission. 17:41:35 Which leads us to jberman's suggestion. 17:44:02 Moving forward: I suggested we give both contestants 2 additional weeks to fix our major issues with their submissions, and allow them both the opportunity to improve their submissions (i.e. they can use a Crandall prime reduction, which is long term what we would hope to integrate into the helioselene lib) 17:45:05 Sounds pretty fair 17:46:12 Sorry, clarifying: 17:46:13 - The bespoke implementation present used `u128`, a Rust-language primitive which defers to the LLVM IR for 128-bit arithmetic. The LLVM IR is observed to generate variable time assembly for its 128-bit arithmetic on nontrivial platforms (and maybe also trivial platforms. Quick, who has an Amiga and a weekend to kill?) 17:46:15 - The forked 'off-the-shelf' implementation, even with the exception granted to one participant universally applied (despite how they were unaware of this exception), forked a library and provided no attribution within the file tree. Beyond the rules regarding plagiarism (to be harsh), this arguably circumvents the 'no additional dependencies' rules by not adding a dependency to t he dependency tree, yet inlining the 20 relevant files from the library into the Helioselene library. The library inlined WAS on the approved dependency list however, so it's a question of if a fork of a dependency counts as approved, what's a reasonable maintenance burden there, etc. Even beyond the ambiguity of 'is it a dependency* however, the lack of attribution *in file tree* would be sufficient to disqualify for improper citations. 17:47:57 jberman and jeffro256 are named as the contest judges. That means they have final judgement, correct? What does jeffro256 think about this? 17:48:13 This is almost fractally complicated :) 17:48:26 I see a 👍️ from jeffro256 on jberman's "Moving forward..." 17:48:53 Contract incompleteness theorem strikes again 17:48:55 Yes, I'm solely a third-party advisor ready to be pedantic, please be aware I don't actually have a standing and now that I've played bad cop, the level-headed people may chime in. 17:49:07 Or is it a theorem? Anyway. 17:49:37 If the contestants agree to it, I agree with the route of allowing 2 additional weeks to refine their submissions, where we explicitly lay out more explicit boundaries around desired behavior, and with the specific feedback for each submission. It will be awkward if one likes the idea, and the other doesn't... 17:49:38 I don't hate we didn't explicitly require the Crandall reduction. I just wouldn't host the contest again. I would host the divisors contest again though, per my current understanding. 17:49:40 By the way, I believe to have seen some @tritonn:matrix.org in the dev channel that wrote about running out of time. Maybe they could submit something with a 2-week extension, who knows 17:50:38 I will add that the second contestant (who forked a library and included in their submission) did ask us how we wanted them to proceed w.r.t attribution for that lib in their PR submission and did clarify where it came from. We missed it / didn't respond to that prior to the deadline 17:50:47 Whether the contestants are amenable to the extension may depend on how they would do (in XMR payments) without it. 17:51:13 And I can fire back that it isn't up to us: it's up to the license they code was used under. 17:51:48 Literally, I can't ask Microsoft how I should handle Apple source code. It's not up to them. 17:52:07 I personally think it would be most fair to the contestants who did get their submissions in time to have the opportunity 17:52:44 I disagree with allowing more people in. 17:53:29 Understandable. It's complicated enough as it is 17:53:51 rbrunner7: I had this same thought, but I lean towards agreeing with @jberman on this one: it wouldn't be fair to the people who submitted in time. Especially since new participants now know where the benchmarks for the "leading" submission stands, whereas before they didn't know that information. 17:54:28 Makes sense 17:55:33 While I have no say in the matter, if no entry is valid, an extension of the contest is a totally fair outcome. Preventing other entries would be unfair. It would only be fair if at least one of the original submissions was valid. 17:56:15 It's due to mixed legality of existing entries and of how there should've been a tighter loop for clarifications/submissions/responses to ensure legality, IMO. 17:57:15 (assuming the code for each entry is not public yet) 17:57:49 Pedantically, none are legal IMO. Reasonably, one of these can be made legal in potentially a few hours. 17:58:08 Yes, the Helios-Selene entries will remain private until further notice. The ec-divisors submission may be made public as soon as we get explicit confirmation from the author 17:59:23 If those two solutions, if possible to get rectified, hoover only around 20% improvement, that's still not very exciting. Is there hope for that "Crandall reduction" to make things substantially faster still? 18:00:14 And is the Crandall reduction modular, or would major parts of the submissions have to be re-written to include it? 18:01:15 Yes rbrunner, and the two of them can still fight it out even if we disallow a third competitor, but if the argument is for a third competitor, so it is. 18:01:47 Rucknium: It's related to how the underlying numeric data is represented, so while it's an algorithm and algorithms are implemented in code and rewritten and ported, it's not pleasant. 18:02:20 But it's not an entire ZK proof, or blockchain. It's an algorithm to take 8 words on a 64-bit computer and reduce it to 4 words. 18:04:36 Another important element to consider here: it seems we may not spend any time integrating these solutions into the lib because the speed-up is not so drastic. With a bit of work, they can be what we would consider technically/pedantically valid submissions that also meet the 20% bar, but without a Crandall prime reduction, and with the relatively minor speed-up they realized, we 18:04:37 may not actually integrate them 18:06:17 True, but IMHO in the light of the contest that would be no real problem: Technically valid and best -> payout. Not useful for us, bad luck 18:07:18 Yea agree 18:07:42 For better or worse, agreed. 18:08:08 I prior said I'd consider this unfortunate and not worth repeating, but would move to accept a patched version of either library so long as they still clear the minimum performance bar. 18:08:42 Except the divisors library seems to have done great, so it's less 'are contests worthwhile' and more 'why did one fail where one succeeded' 18:09:28 Low sample size. Hard to draw a conclusion :P 18:09:56 We could take a survey. Surveys shows 97% of participants like taking surveys. 18:10:16 Ok, I still lean in favor of keeping it to the contestants because it's a small amount of work for them to "fix" their submissions relative to the work they've already done 18:10:26 Exactly. We don't know who looked at the contest and decided not to compete 18:10:44 IMHO, the decision belongs to jberman and jeffro256, including the timeline to make a decision. I think people can continue to give thoughts to them. 18:11:45 Which is why they should only have two days, not two weeks, and even that should be considered generous. In fact, I say we require them eight hours from the end of this meeting, one work day. If the edits aren't done then, then the edits weren't so trivial as to justify this extension. 18:12:23 /s, but I do feel two weeks is VERY generous compared to the amount of time expected for a presumed review + reconcile cycle. 18:13:04 Two weeks for the two submitters seems the most reasonable to me. They may not love it but they'll like that more than being rejected 18:14:27 And this is definitely a lesson in scoping imo. It's especially challenging for open contests because people may be incentived to win on a technicality. The incentive isn't to make the most useful submission, it's to win the game 18:14:56 Nicely put 18:15:01 The contest designers were smart to include the clause "You cannot win on a technicality", which they basically did 18:15:07 I did include this clause for this reason fwiw: 18:15:07 > We reserve the right to select a winner based on our discretion, and rule out submissions for reasons we may not have identified above. For example, if the fastest code has issues we did not identify above, we may select the 2nd fastest code. We aim to ship the winning code in Monero. 18:15:21 Giving those people more time but not others *is* unfair. Giving tiny amounts of time based on one's opinion of how much time is needed for those particular submissions is biased towards those submissions. Agree with the scoping fail point though. 18:15:26 I feel the 20% rule largely helped with this, yet was surprisingly too low a bar given the unfortunately small sample size. 18:15:53 People who didn't submit anything aren't entitled to anything ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯ 18:15:57 Issues such as *not being interoperable with our Ed25519 lib when the entire point is Ed25519 interoperability*? 18:16:14 Right, that's a fundamental issue 18:16:53 False. They're entitled to the same rules as others. 18:17:18 Rules that aren't made to fit those invalid submissions. 18:19:39 Maybe we could look to other contests as how they handled similar situations? 18:20:20 deadline is often adjusted equally for all 18:22:23 One (arguably worse) submission I personally wouldn't argue is invalid because of the licensing question (it's an open question if they would still meet the bar swapping dalek ed25519 back in). I think the other submission (that uses u128 arithmetic which as kayaba noted isn't constant time on all arches but can be fixed) appears superior at this point in time 18:22:46 > It would only be fair if at least one of the original submissions was valid. 18:23:55 One of the submissions I think has a reasonable claim at validity, but appears to be the worse submission, and going by this clause in the contest: 18:23:57 > We reserve the right to select a winner based on our discretion, and rule out submissions for reasons we may not have identified above. For example, if the fastest code has issues we did not identify above, we may select the 2nd fastest code. We aim to ship the winning code in Monero. 18:23:59 Gives us the right to rule it out for its inferiority 18:24:01 Except they can't trivially swap ed25519 back in due to the extensive edits made. 18:24:33 You could decide that no extension will be given, and the contest ended with no acceptable submission. 18:24:57 ^ 18:25:35 Right that's another option. I think it's arguable that is a more fair outcome than opening the contest back up to everyone 18:26:18 2-3 months of time was given, and this is all that the contest got 18:26:19 Closing with no winner can allow another contest, which is equivalent to a large extension for all (and allows for narrower scope). 18:26:37 For the joy of complicating things even more: We could close this and make a new contest :) 18:26:40 And existing entrants still have their code as a leg up. 18:27:13 One submission illegally (US copyright law) included code, even if they asked us how to legally include it (when it's not our decision), and illegally (against the intended contest scope) replaced the Ed25519 field definition. 18:27:13 One submission is variable time and replaced the Ed25519 field definition, but they were told that latter was okay. 18:28:12 Yes, I think the position to refuse to accept both is maybe not "nice", but defensible 18:28:33 Were they told using another lib was fine, or not using ed25519 was fine ? ie, was "another lib" (mis)understood as "another ed25519 lib" ? 18:28:38 At this point, due to the trend of the debate, I'd say extend acceptance for two weeks to everyone, explicitly allow messaging jberman/jeffro256 for clarifications on rules, and one of them cannot unilaterally issue new clarifications. They need to talk it out with each other future. 18:28:43 But it's not my contest :p 18:28:57 it's either theirs, or it's the CCS's who holds the $$$ 18:29:12 IMHO, rules clarification should happen in a public channel, e.g. #monero-dev:libera.chat 18:30:04 IIRC, the payment, if any, would come out of Core's general fund 18:30:41 you may extend the d/l without giving reasons at all... 18:30:43 we'r not in a hurry, are we 18:30:45 Or even as an edit to the rules in the GitHub repo 18:32:37 Were they told using another lib was fine, or not using ed25519 was fine ? ie, was "another lib" (mis)understood as "another ed25519 lib" ? 18:32:37 They were told another lib was fine (they're still using ed25519, just using their own impl). Worth noting still, that submission is still over 20% when using the expected ed25519 lib 18:33:33 We can require all rules clarifications be done via GH issues? 18:33:42 their own implementation of ed25519? Does't that require another audit? 18:33:49 It can be done directly in the github readme 18:35:16 jberman: , jeffro256 : What do you want to do with this discussion? Do you have enough input to make a decision? 18:36:56 I'm not ready to make a decision yet but happy to hear further thoughts / continue the discussion after the meeting. I appreciate the points moneromoo and flip flop raised 18:37:59 5) [Spy nodes](https://github.com/monero-project/research-lab/issues/126). 18:38:24 I made this webapp: https://moneronet.info Like I said, not yet ready to share widely on social media, please 18:38:57 I think it has already given some actionable info: About 50% of honest reachable nodes have the DNS ban list enabled. 18:39:45 50% ?! 18:39:47 That means that it _would_ be worth it to update the DNS ban list to, at least, include all the big spy nodes subnets. The DNS banlist is "full", so a few singleton IPs would have to be dropped 18:40:49 That's according to my analysis. You can infer that a node has a ban list enabled if they share zero nodes on the ban list in their handshake. They share 250 IP addresses, selected from their white_list 18:41:10 It would be fairly trivial to bypass the "full" issue by checking other records. Besides, IP addresses can be represented by integers (ie, raw, not split into bytes). 18:41:19 It may be because SethForPrivacy recommended the DNS ban list flag 18:41:19 https://sethforprivacy.com/guides/run-a-monero-node/ 18:41:21 https://sethforprivacy.com/guides/run-a-monero-node-advanced/ 18:41:52 sry - confused with --ban-list 18:42:07 moneromooo: I agree with that, but it would require an update to the `monerod` code, right? 18:42:29 Yes. I did not realize that was an obstable. 18:43:09 flip flop: Right. The MRL ban list has about 6% adoption. 18:44:28 AFAIK, nodes that check the DNS ban list will pull in the new list once per week, if they do not restart. 18:45:50 About 35% of honest reachable nodes are pruned. And 30% of honest reachable nodes say they have RPC available (But I did not check if they actually have that port open, yet). 18:48:07 That's already a considerable part of nodes pruned ... 18:48:09 The webapp also has an interactive treemap of spy/honest nodes and their subnets, like the static treemap in the draft MRL research bulletin. You can click on the boxes to get more info about each node. I don't think it's mobile-friendly, however. 18:49:35 I'm thinking about computing the Herfindahl-Hirschmann Index of the honest nodes, by subnet and Autonomous System Number (ASN) to measure node "concentration" through time. 18:51:16 The RPC numbers are of interest because they are nodes theoretically susceptible to any RPC vulnerabilities. The Magic Monero Fund has contracted a firm to create an RPC fuzzing harness to anticipate those vulnerabilities. 18:51:41 Any feedback on the webapp is welcome :) 18:52:37 Anything more on spy nodes? 18:53:10 6) CCS proposal: [Monero Network Simulation Tool](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589). 18:54:04 Earlier, gingeropolous said "hi, i've started fiddling with shadow, got it to at least run 2 nodes :/" 18:54:31 (ready to circle back to contest discussion next) 18:55:13 7) Peer Scoring Metrics. 18:55:23 Anything on peer scoring metrics? 18:55:32 would need a serious investment in time and also systems theory. 18:55:56 nothing new. Exept: if a connection handshake for an anchor_node fails for whatever reason, its first_seen value is reset (its thrown out of the anchor_list). 18:55:57 I'd keep it around for say three cx fails. But thats not how apl is designed currently. Just a theoretical thought for now. 18:57:00 Ok we can have the official end of the meeting here. And feel free to continue discussing topics, especially the coding competition. Thanks everyone. 18:58:59 On the contest: 19:00:25