07:38:15 FCMP++ competition details are ready for review: https://github.com/j-berman/fcmp-plus-plus-optimization-competition 07:39:12 I recommend first reading the README at the root, then README's in the 2 directories. I still have some more minor TODO's (the biggest being I want to update the helioselene benchmark tests to calculate the final score) 15:02:19 MRL meeting in this room in two hours. 17:00:29 Meeting time! https://github.com/monero-project/meta/issues/1159 17:00:39 1) Greetings 17:00:52 hello 17:00:53 Hi 17:00:57 Hello 17:01:11 Hello 17:01:33 *waves* 17:02:25 Howdy 17:04:01 2) Updates. What is everyone working on? 17:04:41 me: Some more analysis of subnet deduplication peer selection against spy nodes, preparing all OSPEAD-related documents and code for public release (expected tomorrow), and learning Rust. 17:05:17 Got FCMP++ txs validating at consensus, the FCMP++ optimization competition details are ready for preliminary review, started re-reviewing 9135 17:05:59 FCMP++ dev source (I intend to merge this code with jeffro256 's latest): https://github.com/j-berman/monero/tree/73f0e9202ab6397f43babd4c5c129852d68f8f30 17:06:00 FCMP++ competition: https://github.com/j-berman/fcmp-plus-plus-optimization-competition 17:06:21 Me: Uncovered the reason of the levin protocol header signature. It's a reference to an episode of Futurama series 17:07:22 Me: Working on debugging release issues and review 17:08:25 Bender's Nightmare, mentioned in a comment somewhere 17:09:23 By the way, as a reminder, anyone can suggest MRL agenda items. Just ping me here or in #monero-research-lounge:monero.social , or leave a comment on one of the MRL agenda GitHub issues. I have been composing the agenda based on my own judgement recently. 17:09:28 3) Prize contest to optimize some FCMP cryptography code. https://github.com/j-berman/fcmp-plus-plus-optimization-competition 17:11:49 So main things I did since last week were: 1) settled on a method of scoring helioselene, weighting specific arithmetic operations as a % of the final score, 2) fixed an issue in the wasm-cycles counter used to check for constant time, 3) updated the README's 17:12:44 On 1) I got flamegraphs for prove/verify/hash_grow (weighting much more heavily on the latter 2, because prove's flamegraph is heavily dominated by ec-divisors) to help determine how much to weigh each op 17:13:07 That approach / tje weights could use another set of eyes for sure 17:13:31 Link to the weights: https://github.com/j-berman/fcmp-plus-plus-optimization-competition/tree/b84d9ecf922f9e1a90ab4dae3206a685622e2c69/helioselene-contest#how-your-helioselene-score-is-calculated 17:14:43 Just curious: How hard, according to experience, will it be to achieve constant time execution for the submitted code? 17:15:20 And I wondered whether people may overlook that requirement and then stumble over it 17:15:48 That is an important requirement that I should highlight more significantly 17:16:16 Non-negotiable even? Let's say somebody is twice as fast, but not contant time ... 17:16:59 Why is constant-time so important in this application? Just curious. 17:17:05 I don't know how to answer "how hard" but you can see how the current reference code uses ops like ct_eq and conditional_select to achieve constant time 17:17:27 afaik ocnstant-time is only useful for construction. Nodes that only proceed to verification don't need constant timeness 17:17:47 Sounds logical 17:17:58 kayabanerve: mentioned at one point how it would be relatively trivial to speed up the code by like 300% if non-constant time code was allowed fwiw 17:18:04 Do the point adds include doubling ? There might be different techniques for specifically doubling , I don't know if you want to change the weight based on that 17:18:45 If those 300% are true, that will be quite some temptation 17:19:01 I am tempted likewise rbrunner :D 17:19:07 same 17:19:24 jberman please shatter our dream or we are gonna advocate two implementations :P 17:19:39 one for proving, one for verifying 17:19:41 Constant time is meant to prevent side channel/timing attacks by measuring how long specific functions run, which is a vector to recover the private key material 17:20:02 one for proving that is constant-time, and one for verifying that is variable time 17:20:03 Maybe even submit two different algorithms, with one big "if (construction) else if (verifying)" around it 17:21:09 Yeah, that side channel/timing attack story sure is important, but alas, when veryfing transactions probably not important, right? 17:21:20 point muls do. current point add is composed of field mul/add/sub 17:21:55 https://github.com/j-berman/fcmp-plus-plus-optimization-competition/blob/b84d9ecf922f9e1a90ab4dae3206a685622e2c69/helioselene-contest/helioselene-contest-src/src/point.rs#L82-L139 17:22:07 it's dominated mostly by field mul 17:22:16 like 70% IIRC 17:23:28 it's true, constant time isn't necessary for verifying. That 300% figure was for ec-divisors prove fwiw 17:25:39 Too bad 17:26:10 But well, maybe somebody comes up with an ingenious approach to making constant-time execution code 17:26:31 With much less penalty 17:27:41 kayabanerve has explicitly expressed a lack of interest in maintaining/reviewing multiple implementations. Makes most sense to start with constant time anyway 17:29:45 Speaking of kayabaNerve, last week he said "FYI I will explicitly and publicly opt-out of being a judge, as I already have, yet with the additional comment I may enter (publicly or anonymously) as a contestant in the above proposed contest." https://libera.monerologs.net/monero-research-lab/20250213#c495472 17:30:12 Oh 17:30:49 \> create a contest 17:30:50 \> abandon the contest 17:30:52 \> contest is picked up by someone else 17:30:54 \> "i will participate to the contest" 17:30:58 Thinking by next week's meeting we can get sign-offs on the competition details, then move forward with timeline etc. 17:31:28 jk. obviously not claiming this was what he planned, i'm still happy by this turn of event, im sure kayabanerve will cook up something nice 17:31:28 You forget the line with "Profit!!!" 17:31:58 Yeah, bad joke, I don't want to insinuate anything of this was planned 17:32:17 I mean would be great if kayaba wants to jump in too 17:32:41 Hmmm. Maybe that makes other potential contestants think twice, worst case? 17:33:27 We will see. 17:33:50 rbrunner: it's a risk. 17:34:49 I don't see a significantly better option on the table than this competition to achieve the goal of faster code 17:35:17 Sure. Is this, by the way, the first contest ever for Monero? Might be, no? 17:35:52 The logo contest at the very start does not count :) 17:35:56 IMHO, there are some ethics issues here. Important enough to bar kayaba from participating? I don't know. 17:35:56 I think so, I don't recall any past similar contests 17:36:05 May I recommend some delay between the announcement of the contest and opening the contest? 17:36:31 I'm sure the "cryptography" environment isn't as "excited" as average monero fan, and needs some time to get to the hear of everyone 17:37:07 Ready to move onto the next agenda item, or more to discuss on this? 17:38:00 what do you have in mind? 17:38:02 +1 to announcement first, delay, then contest opens 17:38:45 chaser: Self-dealing is the possible ethics issue 17:39:29 Of course, the potential pool of programmers who could/would participate is probably small, so hard to avoid a "self" in there. 17:40:20 Oh also, I completely forgot. There should be a chinese translation of the contest. China have a much higher pool than the rest of the world. 17:40:39 No i'm not shilling Xin jin ping, our overlord 17:41:21 Rucknium you mean Kayaba raising the funds, writing the code, and then entering the contest to improve the code and winning part the funds he raised? 17:41:37 More, setting the contest rules 17:42:00 Which writing the code in the first place is part of 17:43:38 Perhaps kayaba can provide more color/insight into a decision to participate. I would give a few days for a chance to respond 17:44:12 I don't know. for now I'm not entertaining this possibility. 17:44:29 4) FCMP research progress status. https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/ 17:44:48 Sounds a bit far-fetched alright. I think we will have other, much more surprising problems with the contest 17:45:40 I wanted to bring this up since we haven't talked about it in about a month and a half. Anything we can be doing now to prepare for the next steps of protocol proving and code auditing? 17:46:10 And is the sheet I linked up-to-date? 17:47:21 Sheet is up to date AFAIK. Last I heard, Veridise is making solid progress on their leg of EC divisors R1CS. I haven't heard anything on CS progress. I will get an update 17:47:53 Thanks, jberman 17:48:25 Perhaps we could bring in a new 3rd party to start on some impl audits. There is also the torsion check review that is isolated and can be reviewed by anyone unfamiliar with the rest of FCMP++ components 17:48:48 The latter wasn't explicitly part of the funds raised for the CCS 17:49:31 * m-relay whispers "zellic... zellic... zellic..." 17:49:50 does "CS started (?) // Veridise started (?)" mean we don't know whether they started or not? 17:50:39 I know 100% Veridise started, I'm not 100% sure on CS. I'll double check 17:50:59 thank you! 17:51:57 Would the torsion check review be a review of mathematics or a code audit? 17:51:58 as for "Gadgets formal verification", has Veridise been sent a request? 17:52:00 I'll check up on starting impl audits too. Seems reasonable to start those 17:52:53 Mathematics. The code is pretty small 17:53:11 sorry if it's too many questions, I'm just trying to understand the spreadsheet 17:53:27 AFAIK no. Seems sensible to wait on them to complete their current work 17:54:50 ah, alright. I suppose they're a small team and they're now fully occupied with the R1CS proofs 17:56:01 Maybe they do have others available, that's a good point. Will follow up on that as well 17:57:07 presuming this work is parallelizable with the EC divisors part 17:57:39 * sech1 sighs. That competitions being Rust-only cuts a lot of devs, including me 17:58:20 jberman and given that there is no other viable candidate 17:58:26 I knew it. kayaba eliminating the competition hahahaha 17:58:46 (This is a joke) 17:59:13 sech1: never too late to learn Rust (i can understand the disappointment for a C/C++ dev) 17:59:27 @sech1 rust is really not that hard to learn 😏 17:59:54 But hey, getting so good at it in weeks as to win a contest, I don't know :) 18:00:32 I'm sure it's easy to learn... but hard to master (to be competitive), as all things 18:00:40 Too late for me to enter this competition 18:01:19 you can always try to team up with a Crab master and he will translate your improvements 18:01:33 I think the core of this competition will be implementing faster algorithms, not necessarily niche micro-optimizations that are language specific 18:02:14 algorithmic optimization, not code optimization 18:03:04 5) Fluffy blocks efficiency improvements. 18:03:20 jeffro256 was looking into this ^ 18:03:36 "Crandall prime with fast reduction algorithms available accordingly.", and "This would enable implementing ECFFT, reducing the computational complexity of ec-divisors." sounds like a plan already, and then what's left will be micro-optimizations that will require extensive knowledge of Rust 18:05:37 I'll be surprised I guess if it's someone's knowledge of rust that puts them over the edge of another submission as opposed to better algos 18:05:51 is there a link to get a better meta on the fluffy blocks improvements topic? 18:06:11 chaser: AFAIK, it is very early stages 18:06:38 Yes. I think we're probably going to merge #9135 with relaying empty blocks at first , but it would be nice to know if the scheme of relaying transactions you didn't know about doesn't leak information 18:07:01 Because its almost guaranteed to be faster in an average case 18:07:58 Oh, it's part of that PR? Ok. 18:08:08 https://github.com/monero-project/monero/pull/9135#discussion_r1957451272 18:08:33 This is the discussion 18:08:49 It should be noted that we can always change the scheme later 18:08:57 It's all compatible with one another 18:09:30 fwiw relaying empty blocks seemed ok to me, I also wanted to re-review that full flow of requesting missing / responding 18:09:54 want to re-review* 18:10:57 At first glance, I think there could be a small info leak because relaying a block and relaying a fluff-phase tx aren't completely equivalent because fluff-phase txs are relayed with a random delay, but blocks are immediate AFAIK. But on the other hand, at current network conditions, few txs would be in this situation. 18:12:45 I could check it empirically in the node logs from last year since the log level recorded fluffy blocks and when txs were "missed" by the nodes. But anyway, centralized mining pools still do not update their block templates instantly when the get new txs. IIRC, they are on about 20-30 second cycles. And txs propagate throughout the network during the fluff phase in two seconds or less. 18:13:13 rbrunner Rucknium Non-constant-time means leaked private keys and no privacy under side-channel attacks. 18:13:37 That 300% comment wasn't for node operations. It was for proving. The part that *needs* to be constant-time. 18:14:30 Oh, jberman did clarify the context of the 300% comment 👍 18:15:57 It would give miners a competitive advantage to puts txs into the block as soon as they see them though? 18:16:35 Yes, but they still don't do that. 18:16:40 If that 20-30 second cycle thing really is true then that should be changed IMO 18:16:56 that's bad for confirmation turnaround time 18:17:13 [@syntheticbird:monero.social](https://matrix.to/#/@syntheticbird:monero.social) I didn't propose a contest with an annual extrapolated pay of >1m to the winner :p I can lose interest as a volunteer and reacquire interest upon sufficient payment. 18:18:04 If there are sufficient ethical concerns, I'll drop out though. I'll note jberman has been working on the scoring framework without my commentary other than what little I've said here. I also haven't advocated for larger prizes and didn't write the rules with intent to participate. 18:18:11 I already fought this battle, and this is the compromise that mining pools arrived at 18:19:21 kayabanerve: I don't think that the discussion here in this meeting raised to the level of "sufficient ethical concerns" for you to drop out. 18:19:42 fwiw the total proposed payout right now is 350 XMR (250+100) after taking into consideration the estimate for expected time to complete. Original proposed was 300 XMR (150+75 + 50+25) 18:19:46 In other words, right now it looks like loose consensus to allow you to participate. 18:20:33 e.g. HashVault's refresh is 20 seconds after I published my research: https://old.reddit.com/r/Monero/comments/10gapp9/centralized_mining_pools_are_delaying_monero/j52n5uc/ 18:20:53 jberman: Math and impl. I'm not convinced the impl matches the paper and think it's a further derivative. Then, even if the theory is sound, if your code doesn't match, it risks questions about inflation. 18:21:22 Ya, fair. I think all of impl could use auditing fwiw 18:22:17 sech1: I don't believe Rust, at this level of programming, should be a blocker. The end-goal of the Helioselene arithmetic is just operations over arrays which Rust doesn't really do with novelty UNLESS you explicitly expect the C preprocessor. 18:23:08 The FFT code is also mathematical theory. The divisors preprocessing is just bit operations. The question is there a more intelligent series than the 3 O(n**2) steps currently present. 18:23:24 TBC, it seems like we'd want paper math reviewed, then the code math which deviates formalized and reviewed, then the code impl reviewed 18:23:51 Sorry. I didn't realize the meeting was still ongoing. Apologies for talking past the current discussion. I'm caught up now. 18:24:26 don't apologies people were waiting on your inputs 18:24:28 Or to use it for wallets only where it's only a liveness issue if it breaks. 18:24:29 now you may proceed to apologies for apologizing 18:24:44 (or combine first two together as one mathematics review) 18:25:15 I think we should still use it for wallets only and is probably worth a focused review anyway 18:25:22 I will also accept 1m/y to operate the contest, and not participate accordingly, for the time I spend working on the contest :p 18:28:25 I'm not trying to be rude, I'm just being explicitly clear my interest in this contest isn't due to my free time or personal love for the subject. I believe the current code is fine. It just got bumped up to a very large $ figure after I dropped it. 18:28:54 i dont find it rude 18:29:07 i love money so it make sense to me 18:29:08 Eh, it's at least a bit cutthroat/ruthless/merc 18:29:31 It got bumped in discussions where we weren't accurately taking into consideration expected time to complete the work. It was brought down again after taking your prior estimate into consideration 18:30:11 And like magic, I've lost interest and will go find other places to pay my bills 18:30:16 :p 18:30:28 lol 18:31:16 We can end the meeting here. Feel free to continue discussing things. 18:31:28 I don't think anyone can "allow" someone to participate, since the contest allows pseudonymous submissions. if it's assumed that Kayaba is self-dealing, they could just enter under a different name. and, if not, then please participate, by all means necessary. 18:32:40 kayabanerve I will take a look of course at the competition tasks, from the algorithmic perspective. But my progress will be slowed down by almost 0 knowledge of Rust, so there's that. I'm sure I will be able to get through this, but my implementation can suffer from some stupid performance mistake that I don't know about in Rust 18:33:12 sech1 really you should team up with someone else 18:33:23 I'll be honest about if I may participate. It's only if I was dishonest that I could compete without approval (or at least without backlash). 18:33:34 I would "team up" with an AI to check my code, but it's not allowed in the competition 18:33:43 we can request kayaba not participate as a show of good faith and knowing kayaba, I imagine would honor it. I think the ethics concern is understandable to some degree, and was first voiced by a potential contestant who doesn't want to participate anymore 18:33:46 but wait, is it allowed to just check the code for possible performance issues? 18:34:32 sech1 "LLM generated code is prohibited", as long as our overlord DeepSeek don't write a fix it's ok on paper 18:34:52 I would write code myself, with AI guidance about Rust-specific details 18:34:59 jberman: BTW, Rust 1.84 added wasm32v1-none which is without platform-specific architectural extensions. The contest should likely compile with it (not wasm32-unknown-unknown) to prevent concerns re: autovectorization. 18:35:33 sech1: Evaluation box is public. I think the scoring framework was publicized by jberman. 18:36:01 well, that makes things easier. sgtm 18:36:34 what is the time frame for the competition? How long will it last? 18:36:40 I'm going to take out the AI/LLM thing. if the code works the code works. I guess concern was over licensing issues? 18:37:08 50% of the time, AI code works all the time :D 18:37:31 I was thinking 2 months from contest open to close 18:37:38 my concern is about human dignity and being able to look at yourself in the mirror ngl. But the "The end justify the means" outreach human condition. 18:37:38 maybe 3? 18:37:39 I wouldn't rely on AI and just copy-paste their (its?) code 18:38:28 For me, AI is a tool, not a "make it work" button 18:38:40 jberman: I'm not merging LLM-generated code or code with a reasonable suspicion it may have been LLM-generated into my personal tree. 18:38:53 I don't consider it ethical not safe. 18:39:09 LLM-assisted developers have higher confidence in their code despite lower quality. 18:39:25 How would you know it's LLM-generated? Where is the line? Is autocomplete is IDEs an AI? 18:39:30 *in IDEs 18:39:31 Monero doesn't need greater confidence in worse code. It needs proper confidence in solid code. 18:39:32 sech1: I don't particularly target you with my statement, i believe you are good enough to expect a tool to act as a tool. 18:40:03 I was more talking about people fully generating their code and whom their work is "prompt engineering" 18:40:12 If I enter the competition I will be LLM-assisted only by necessity. I wouldn't need it for C/C++ 18:40:24 LLM-generated code has a vibe to it. I also had it in their rules so only a dishonest participant would use an LLM. I believe that rule, plus reasonable evaluation, would be sufficient. 18:40:41 Also, auto complete generally doesn't use ML so it obviously wouldn't qualify. 18:40:51 Ok if LLM-generated code wins the competition I'll rewrite the code 18:40:51 Apart from licensing isssues, a good test suite will filter out any bad code 18:40:59 Zed editor would like to have a word 18:41:13 (Yes autocomplete can now be LLM powered) 18:41:15 sech1: I don't care how you waste your time. I just care no spam enters into the code I have to deal with, if I have to deal with it. 18:41:34 I said already I won't be copy-pasting 18:41:49 I like to know my code from top to bottom 18:41:55 otherwise I wouldn't understand what to do with it 18:42:03 jberman: You're either throwing out the winner or laundering. Either way, you're not doing something proper. 18:42:20 That's why it's an explicit disqualification currently. 18:42:26 I don't really understand your argument here 18:42:32 I'm just being open about my LLM usage 18:42:44 sech1: Heard. Please see "I don't care how you waste your time". I have no issues between us right now. 18:43:21 If you think that I will waste my time befcause someone else will have a better implementation, maybe I shouldn't try then 18:43:31 sech1 he was talking to jberman not you 18:43:35 jberman: If the winner is LLM generated, and you rewrite it: 18:43:36 Are you writing a distinct solution or are you just making it so the teacher doesn't notice you copied someone else's homework? 18:43:48 If the latter, there's all of the same issues. You just laundered the LLM output. 18:43:48 replying to jberman proposing to rewrite manually an AI generated winner 18:44:11 Plus I don't think an LLM will be able to write a meaningful working code for this competition 18:44:24 It will need to be tightly guided, step by step and with small pieces of code 18:44:25