Monero Research Lab Meeting - Wed 19 February 2025, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. Prize contest to optimize some FCMP cryptography code.

4. FCMP research progress status.

5. Fluffy blocks efficiency improvements.

6. Research on subnet deduplication for peer selection to reduce spy node risk.

7. Any other business

8. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#1155

[Rucknium]

Logs

< j​berman:monero.social > FCMP++ competition details are ready for review: https://github.com/j-berman/fcmp-plus-plus-optimization-competition

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

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

< r​ucknium:monero.social > Meeting time! #1159

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

< c​haser:monero.social > hello

< s​yntheticbird:monero.social > Hi

< rbrunner > Hello

< s​agewilder:unredacted.org > Hello

< j​berman:monero.social > waves

< j​effro256:monero.social > Howdy

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

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

< j​berman:monero.social > Got FCMP++ txs validating at consensus, the FCMP++ optimization competition details are ready for preliminary review, started re-reviewing 9135

< j​berman:monero.social > FCMP++ dev source (I intend to merge this code with jeffro256 's latest): https://github.com/j-berman/monero/tree/73f0e9202ab6397f43babd4c5c129852d68f8f30

< j​berman:monero.social > FCMP++ competition: https://github.com/j-berman/fcmp-plus-plus-optimization-competition

< s​yntheticbird:monero.social > Me: Uncovered the reason of the levin protocol header signature. It's a reference to an episode of Futurama series

< j​effro256:monero.social > Me: Working on debugging release issues and review

< rbrunner > Bender's Nightmare, mentioned in a comment somewhere

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

< r​ucknium:monero.social > 3) Prize contest to optimize some FCMP cryptography code. https://github.com/j-berman/fcmp-plus-plus-optimization-competition

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

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

< j​berman:monero.social > That approach / tje weights could use another set of eyes for sure

< j​berman:monero.social > Link to the weights: https://github.com/j-berman/fcmp-plus-plus-optimization-competition/tree/b84d9ecf922f9e1a90ab4dae3206a685622e2c69/helioselene-contest#how-your-helioselene-score-is-calculated

< rbrunner > Just curious: How hard, according to experience, will it be to achieve constant time execution for the submitted code?

< rbrunner > And I wondered whether people may overlook that requirement and then stumble over it

< j​berman:monero.social > That is an important requirement that I should highlight more significantly

< rbrunner > Non-negotiable even? Let's say somebody is twice as fast, but not contant time ...

< r​ucknium:monero.social > Why is constant-time so important in this application? Just curious.

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

< s​yntheticbird:monero.social > afaik ocnstant-time is only useful for construction. Nodes that only proceed to verification don't need constant timeness

< rbrunner > Sounds logical

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

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

< rbrunner > If those 300% are true, that will be quite some temptation

< r​ucknium:monero.social > I am tempted likewise rbrunner :D

< s​yntheticbird:monero.social > same

< s​yntheticbird:monero.social > jberman please shatter our dream or we are gonna advocate two implementations :P

< s​yntheticbird:monero.social > one for proving, one for verifying

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

< s​yntheticbird:monero.social > one for proving that is constant-time, and one for verifying that is variable time

< rbrunner > Maybe even submit two different algorithms, with one big "if (construction) else if (verifying)" around it

< rbrunner > Yeah, that side channel/timing attack story sure is important, but alas, when veryfing transactions probably not important, right?

< j​berman:monero.social > point muls do. current point add is composed of field mul/add/sub

< j​berman:monero.social > https://github.com/j-berman/fcmp-plus-plus-optimization-competition/blob/b84d9ecf922f9e1a90ab4dae3206a685622e2c69/helioselene-contest/helioselene-contest-src/src/point.rs#L82-L139

< j​berman:monero.social > it's dominated mostly by field mul

< j​berman:monero.social > like 70% IIRC

< j​berman:monero.social > it's true, constant time isn't necessary for verifying. That 300% figure was for ec-divisors prove fwiw

< rbrunner > Too bad

< rbrunner > But well, maybe somebody comes up with an ingenious approach to making constant-time execution code

< rbrunner > With much less penalty

< j​berman:monero.social > kayabanerve has explicitly expressed a lack of interest in maintaining/reviewing multiple implementations. Makes most sense to start with constant time anyway

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

< rbrunner > Oh

< s​yntheticbird:monero.social > > create a contest

< s​yntheticbird:monero.social > > abandon the contest

< s​yntheticbird:monero.social > > contest is picked up by someone else

< s​yntheticbird:monero.social > > "i will participate to the contest"

< j​berman:monero.social > Thinking by next week's meeting we can get sign-offs on the competition details, then move forward with timeline etc.

< s​yntheticbird:monero.social > 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

< rbrunner > You forget the line with "Profit!!!"

< rbrunner > Yeah, bad joke, I don't want to insinuate anything of this was planned

< j​berman:monero.social > I mean would be great if kayaba wants to jump in too

< rbrunner > Hmmm. Maybe that makes other potential contestants think twice, worst case?

< rbrunner > We will see.

< c​haser:monero.social > rbrunner: it's a risk.

< j​berman:monero.social > I don't see a significantly better option on the table than this competition to achieve the goal of faster code

< rbrunner > Sure. Is this, by the way, the first contest ever for Monero? Might be, no?

< rbrunner > The logo contest at the very start does not count :)

< r​ucknium:monero.social > IMHO, there are some ethics issues here. Important enough to bar kayaba from participating? I don't know.

< j​berman:monero.social > I think so, I don't recall any past similar contests

< s​yntheticbird:monero.social > May I recommend some delay between the announcement of the contest and opening the contest?

< s​yntheticbird:monero.social > 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

< r​ucknium:monero.social > Ready to move onto the next agenda item, or more to discuss on this?

< c​haser:monero.social > what do you have in mind?

< j​berman:monero.social > +1 to announcement first, delay, then contest opens

< r​ucknium:monero.social > chaser: Self-dealing is the possible ethics issue

< r​ucknium:monero.social > Of course, the potential pool of programmers who could/would participate is probably small, so hard to avoid a "self" in there.

< s​yntheticbird:monero.social > 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.

< s​yntheticbird:monero.social > No i'm not shilling Xin jin ping, our overlord

< c​haser:monero.social > 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?

< r​ucknium:monero.social > More, setting the contest rules

< r​ucknium:monero.social > Which writing the code in the first place is part of

< j​berman:monero.social > Perhaps kayaba can provide more color/insight into a decision to participate. I would give a few days for a chance to respond

< c​haser:monero.social > I don't know. for now I'm not entertaining this possibility.

< r​ucknium:monero.social > 4) FCMP research progress status. https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/

< rbrunner > Sounds a bit far-fetched alright. I think we will have other, much more surprising problems with the contest

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

< r​ucknium:monero.social > And is the sheet I linked up-to-date?

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

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

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

< j​berman:monero.social > The latter wasn't explicitly part of the funds raised for the CCS

* m-relay <s​yntheticbird:monero.social> whispers "zellic... zellic... zellic..."

< c​haser:monero.social > does "CS started (?) // Veridise started (?)" mean we don't know whether they started or not?

< j​berman:monero.social > I know 100% Veridise started, I'm not 100% sure on CS. I'll double check

< c​haser:monero.social > thank you!

< r​ucknium:monero.social > Would the torsion check review be a review of mathematics or a code audit?

< c​haser:monero.social > as for "Gadgets formal verification", has Veridise been sent a request?

< j​berman:monero.social > I'll check up on starting impl audits too. Seems reasonable to start those

< j​berman:monero.social > Mathematics. The code is pretty small

< c​haser:monero.social > sorry if it's too many questions, I'm just trying to understand the spreadsheet

< j​berman:monero.social > AFAIK no. Seems sensible to wait on them to complete their current work

< c​haser:monero.social > ah, alright. I suppose they're a small team and they're now fully occupied with the R1CS proofs

< j​berman:monero.social > Maybe they do have others available, that's a good point. Will follow up on that as well

< c​haser:monero.social > presuming this work is parallelizable with the EC divisors part

* sech1 sighs. That competitions being Rust-only cuts a lot of devs, including me

< c​haser:monero.social > jberman and given that there is no other viable candidate

< r​ucknium:monero.social > I knew it. kayaba eliminating the competition hahahaha

< r​ucknium:monero.social > (This is a joke)

< s​yntheticbird:monero.social > sech1: never too late to learn Rust (i can understand the disappointment for a C/C++ dev)

< j​berman:monero.social > sech1: rust is really not that hard to learn 😏

< rbrunner > But hey, getting so good at it in weeks as to win a contest, I don't know :)

< sech1 > I'm sure it's easy to learn... but hard to master (to be competitive), as all things

< sech1 > Too late for me to enter this competition

< s​yntheticbird:monero.social > you can always try to team up with a Crab master and he will translate your improvements

< j​berman:monero.social > I think the core of this competition will be implementing faster algorithms, not necessarily niche micro-optimizations that are language specific

< s​yntheticbird:monero.social > algorithmic optimization, not code optimization

< r​ucknium:monero.social > 5) Fluffy blocks efficiency improvements.

< r​ucknium:monero.social > jeffro256 was looking into this ^

< sech1 > "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

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

< c​haser:monero.social > is there a link to get a better meta on the fluffy blocks improvements topic?

< r​ucknium:monero.social > chaser: AFAIK, it is very early stages

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

< j​effro256:monero.social > Because its almost guaranteed to be faster in an average case

< r​ucknium:monero.social > Oh, it's part of that PR? Ok.

< j​effro256:monero.social > monero-project/monero#9135 (comment)

< j​effro256:monero.social > This is the discussion

< j​effro256:monero.social > It should be noted that we can always change the scheme later

< j​effro256:monero.social > It's all compatible with one another

< j​berman:monero.social > fwiw relaying empty blocks seemed ok to me, I also wanted to re-review that full flow of requesting missing / responding

< j​berman:monero.social > want to re-review*

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

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

< k​ayabanerve:monero.social > rbrunner Rucknium Non-constant-time means leaked private keys and no privacy under side-channel attacks.

< k​ayabanerve:monero.social > That 300% comment wasn't for node operations. It was for proving. The part that needs to be constant-time.

< k​ayabanerve:monero.social > Oh, jberman did clarify the context of the 300% comment 👍

< j​effro256:monero.social > It would give miners a competitive advantage to puts txs into the block as soon as they see them though?

< r​ucknium:monero.social > Yes, but they still don't do that.

< j​effro256:monero.social > If that 20-30 second cycle thing really is true then that should be changed IMO

< j​effro256:monero.social > that's bad for confirmation turnaround time

< k​ayabanerve:monero.social > 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.

< k​ayabanerve:monero.social > 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.

< r​ucknium:monero.social > I already fought this battle, and this is the compromise that mining pools arrived at

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

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

< r​ucknium:monero.social > In other words, right now it looks like loose consensus to allow you to participate.

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

< k​ayabanerve:monero.social > 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.

< j​berman:monero.social > Ya, fair. I think all of impl could use auditing fwiw

< k​ayabanerve:monero.social > 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.

< k​ayabanerve:monero.social > 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.

< j​berman:monero.social > TBC, it seems like we'd want paper math reviewed, then the code math which deviates formalized and reviewed, then the code impl reviewed

< k​ayabanerve:monero.social > Sorry. I didn't realize the meeting was still ongoing. Apologies for talking past the current discussion. I'm caught up now.

< s​yntheticbird:monero.social > don't apologies people were waiting on your inputs

< k​ayabanerve:monero.social > Or to use it for wallets only where it's only a liveness issue if it breaks.

< s​yntheticbird:monero.social > now you may proceed to apologies for apologizing

< j​berman:monero.social > (or combine first two together as one mathematics review)

< j​berman:monero.social > I think we should still use it for wallets only and is probably worth a focused review anyway

< k​ayabanerve:monero.social > I will also accept 1m/y to operate the contest, and not participate accordingly, for the time I spend working on the contest :p

< k​ayabanerve:monero.social > 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.

< s​yntheticbird:monero.social > i dont find it rude

< s​yntheticbird:monero.social > i love money so it make sense to me

< k​ayabanerve:monero.social > Eh, it's at least a bit cutthroat/ruthless/merc

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

< k​ayabanerve:monero.social > And like magic, I've lost interest and will go find other places to pay my bills

< k​ayabanerve:monero.social > :p

< j​berman:monero.social > lol

< r​ucknium:monero.social > We can end the meeting here. Feel free to continue discussing things.

< c​haser:monero.social > 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.

< sech1 > 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

< s​yntheticbird:monero.social > sech1 really you should team up with someone else

< k​ayabanerve:monero.social > 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).

< sech1 > I would "team up" with an AI to check my code, but it's not allowed in the competition

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

< sech1 > but wait, is it allowed to just check the code for possible performance issues?

< s​yntheticbird:monero.social > sech1 "LLM generated code is prohibited", as long as our overlord DeepSeek don't write a fix it's ok on paper

< sech1 > I would write code myself, with AI guidance about Rust-specific details

< k​ayabanerve:monero.social > 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.

< k​ayabanerve:monero.social > sech1: Evaluation box is public. I think the scoring framework was publicized by jberman.

< j​berman:monero.social > well, that makes things easier. sgtm

< sech1 > what is the time frame for the competition? How long will it last?

< j​berman:monero.social > I'm going to take out the AI/LLM thing. if the code works the code works. I guess concern was over licensing issues?

< sech1 > 50% of the time, AI code works all the time :D

< j​berman:monero.social > I was thinking 2 months from contest open to close

< s​yntheticbird:monero.social > 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.

< j​berman:monero.social > maybe 3?

< sech1 > I wouldn't rely on AI and just copy-paste their (its?) code

< sech1 > For me, AI is a tool, not a "make it work" button

< k​ayabanerve:monero.social > jberman: I'm not merging LLM-generated code or code with a reasonable suspicion it may have been LLM-generated into my personal tree.

< k​ayabanerve:monero.social > I don't consider it ethical not safe.

< k​ayabanerve:monero.social > LLM-assisted developers have higher confidence in their code despite lower quality.

< sech1 > How would you know it's LLM-generated? Where is the line? Is autocomplete is IDEs an AI?

< sech1 > *in IDEs

< k​ayabanerve:monero.social > Monero doesn't need greater confidence in worse code. It needs proper confidence in solid code.

< s​yntheticbird:monero.social > 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.

< s​yntheticbird:monero.social > I was more talking about people fully generating their code and whom their work is "prompt engineering"

< sech1 > If I enter the competition I will be LLM-assisted only by necessity. I wouldn't need it for C/C++

< k​ayabanerve:monero.social > 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.

< k​ayabanerve:monero.social > Also, auto complete generally doesn't use ML so it obviously wouldn't qualify.

< j​berman:monero.social > Ok if LLM-generated code wins the competition I'll rewrite the code

< sech1 > Apart from licensing isssues, a good test suite will filter out any bad code

< s​yntheticbird:monero.social > Zed editor would like to have a word

< s​yntheticbird:monero.social > (Yes autocomplete can now be LLM powered)

< k​ayabanerve:monero.social > 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.

< sech1 > I said already I won't be copy-pasting

< sech1 > I like to know my code from top to bottom

< sech1 > otherwise I wouldn't understand what to do with it

< k​ayabanerve:monero.social > jberman: You're either throwing out the winner or laundering. Either way, you're not doing something proper.

< k​ayabanerve:monero.social > That's why it's an explicit disqualification currently.

< j​berman:monero.social > I don't really understand your argument here

< sech1 > I'm just being open about my LLM usage

< k​ayabanerve:monero.social > sech1: Heard. Please see "I don't care how you waste your time". I have no issues between us right now.

< sech1 > If you think that I will waste my time befcause someone else will have a better implementation, maybe I shouldn't try then

< s​yntheticbird:monero.social > sech1 he was talking to jberman not you

< k​ayabanerve:monero.social > jberman: If the winner is LLM generated, and you rewrite it:

< k​ayabanerve:monero.social > Are you writing a distinct solution or are you just making it so the teacher doesn't notice you copied someone else's homework?

< k​ayabanerve:monero.social > If the latter, there's all of the same issues. You just laundered the LLM output.

< s​yntheticbird:monero.social > replying to jberman proposing to rewrite manually an AI generated winner

< sech1 > Plus I don't think an LLM will be able to write a meaningful working code for this competition

< sech1 > It will need to be tightly guided, step by step and with small pieces of code

< k​ayabanerve:monero.social > sech1: No. I'm saying I think you using a LLM is a waste of your time. I don't think competing is a waste of your time. I tried to encourage you to do so.

< j​berman:monero.social > Where is the "wrong" thing? LLM's generating code and then them not attributing properly and so downstream user of teh code not attributing properly?

< sech1 > Why waste of my time? If I get some Rust compiler error (which I know nothing about), it will be faster to ask an LLM wtf is wrong than google the answer

< j​berman:monero.social > "copying someone else's homework" it's FOSS..

< k​ayabanerve:monero.social > I think you can pick up sufficient Rust trivially or find the necessary educational resources without going to a bottom-barrel plagiarist who consistently hallucinates, even if hallucinations are less discussed now.

< k​ayabanerve:monero.social > jberman:

< k​ayabanerve:monero.social > > LLM-assisted developers have higher confidence in their code despite lower quality.

< k​ayabanerve:monero.social > That and the ethical issues.

< k​ayabanerve:monero.social > That's not what FOSS means.

< sech1 > I tested LLMs and I have 0 confidence about their ability to write code longer than 10-20 lines at a time :D

< k​ayabanerve:monero.social > FOSS doesn't mean you're allowed to copy without care.

< sech1 > Even 10 lines C++ programs I tested had issues and needed to be guided to fix them

< j​berman:monero.social > As judges we're going to review the code quality

< k​ayabanerve:monero.social > sech1: That's why I think LLMs are a waste of time.

< sech1 > Not a waste of time to explain some Rust syntax of compiler errors, that's my plan

< k​ayabanerve:monero.social > You're welcome to disagree though, I don't have to care here and don't mean to scare you off.

< sech1 > *or compiler errors

< k​ayabanerve:monero.social > I still disagree :p But that's fine, we can.

< sech1 > Honestly I would prefer C for this competition. It's "unsafe" only in incapable hands.

< b​oog900:monero.social > Lol

< s​yntheticbird:monero.social > you just paint yourself a target for all rustacean in the chat

< j​berman:monero.social > yes so your ethics concern is with LLM not attributing properly and then downstream using the code, and also therefore not attributing properly by default sounds like

< sech1 > Rust being "safe" doesn't automatically make it safe

< sech1 > Sure, it eliminates whole classes of errors (that juniors and mids do in C/C++), but not all of them

< s​yntheticbird:monero.social > not saying you are wrong (i think it's wrong) but clearly all rustacean have been indoctrinated in counter-argumenting this specific "skill issue" argument

< k​ayabanerve:monero.social > There's an ethics concern and a safety concern. Reviewers shouldn't be further burdened.

< sech1 > A dangerous delusion about Rust I feel in the programming community

< k​ayabanerve:monero.social > sech1: It achieves a specific definition of memory safety, which is a very large class of bugs.

< k​ayabanerve:monero.social > *barring compiler bugs

< sech1 > Except memory leaks. Memory leaks are fine :D

< k​ayabanerve:monero.social > Then the std lib, libraries in general, practice solid design patterns to build code with.

< s​yntheticbird:monero.social > sech1: Don't mind the community, they are delusional as all programming communities. Even if you disagree, profit from their tech, it'll make your life easier.

< s​yntheticbird:monero.social > Rust is a great programming langauge

< s​yntheticbird:monero.social > Rust is a great programming language

< k​ayabanerve:monero.social > Memory leaks aren't unsafe. They don't risk out of bound read/writes.

< sech1 > I don't argue about Rust being great at what it does.

< sech1 > But C/C++, with enough skill, is not worse

< k​ayabanerve:monero.social > Nor segfaults, nor unaligned operations, nor...

< sech1 > Out of bound read/writes are not a thing in C++ if you you std containters only and know how to do it

< k​ayabanerve:monero.social > It just places a much higher burden on the developer as there's no longer the automated system ensuring it.

< sech1 > anyway, the discussion went off rails

< s​yntheticbird:monero.social > I like trains

< s​yntheticbird:monero.social > 👍

< k​ayabanerve:monero.social > Uhhh I think Vector indexing allows out-of-bounds reads.

< sech1 > range-for loops and std::for_each would like to have a word

< k​ayabanerve:monero.social > So I really contest 'std containers only and know how to do it' when they blatantly provide unsafe methods

< sech1 > modern C++ is safe

< j​berman:monero.social > anyone else here think LLM's are unethical?

< k​ayabanerve:monero.social > No, but like, x[1] where x is a Vector is unsafe.

< s​yntheticbird:monero.social > There is a bounds checking compiled so you will immediately crash. no undefined behavior

< k​ayabanerve:monero.social > SyntheticBird: Vector

< s​yntheticbird:monero.social > unlike C++

< k​ayabanerve:monero.social > C++

< k​ayabanerve:monero.social > Not Vec

< s​yntheticbird:monero.social > Ah my bad

< k​ayabanerve:monero.social > If the immediate way to index one of the most popular C++ std containers is unsafe, I contest modern C++/the std is safe.

< sech1 > C++ just doesn't give this guarantee on the language level. But you can write a C++ program without a single index operator and still have loops and vectors and so on

< k​ayabanerve:monero.social > Yeah, sure. You can carefully define a subset and manually ensure you're within it.

< k​ayabanerve:monero.social > Or you can use an explicitly formally verified subset, as exist, to remove that developer burden.

< sech1 > not a burden for a skilled developer, merely a matter of habit

< k​ayabanerve:monero.social > Or you can use Rust which isn't a C subset but has a full language and ecosystem.

< sech1 > and be performance limited by range checks at every [] operator, right?

< k​ayabanerve:monero.social > Yeah, it's a habit for me to use get instead of [], I still occasionally use [] by accident.

< k​ayabanerve:monero.social > (One implicitly panics)

< s​yntheticbird:monero.social > sech1: it's not that bad as it sounds, compiler do a pretty good job at bound checking analysis

< sech1 > tldr Rust is "safe", but not formally, mathematically "safe". Code review, audits etc are still required

< k​ayabanerve:monero.social > Isn't Rust just 3-7% slower in a variety of case studies?

< s​yntheticbird:monero.social > I heard the same numbers

< sech1 > So C++ and Rust are just a different shades of "safe"

< s​yntheticbird:monero.social > 3% if you disable overflow check

< s​yntheticbird:monero.social > sech1: There is a subset of Rust (i forgot the name but shared it to jberman) that is formally verified for cryptographic purposes

< sech1 > great

< c​haser:monero.social > I don't see an ethical issue if it helps us find a faster algorithm. the burden on the reviewers due to the fact that LLMs mostly write slop is an angle I haven't considered and may have merit

< sech1 > now there is a subset of Rust :D

< s​yntheticbird:monero.social > https://hacspec.org/

< sech1 > But the current implementation doesn't use it, right?

< b​oog900:monero.social > I don't think LLM's should be allowed, although if you can't tell an LLM was used then the submission can't be disqualified ;)

< s​yntheticbird:monero.social > ;)

< s​yntheticbird:monero.social > # ;)

< sech1 > Very true. If the code compiles and passes all tests, was there an LLM? Who knows?

< b​oog900:monero.social > often you can smell it, but if you use it very sparingly like what you wanted sech1 then I see no issue.

< s​yntheticbird:monero.social > Can we add a rule to prohibit flutter bridged AI generated rust bindings. I don't want Kewbit to announce a 90% completed heliosene implementation

< j​berman:monero.social > LLM slop isn't going to win this competition, and if by some miracle chance it does and the code reveals a sound approach, which I would be utterly shocked by also, it should honestly be trivial to rewrite. the challenge is going to be in finding the sound approach

< b​oog900:monero.social > then we should reward the LLM!

< b​oog900:monero.social > not the person that submitted it

< k​ayabanerve:monero.social > Ethics ^

< k​ayabanerve:monero.social > Where's a stonks meme but just "efiks"

< sech1 > LLM is not a legal entity (yet), so you can't reward it.

< s​yntheticbird:monero.social > AI rights

< s​yntheticbird:monero.social > soonTM

< sech1 > Even my dog has more rights than LLMs

< s​yntheticbird:monero.social > krita don't stop crashing in my VM (I blame ZCash) sorry, can't do that on the fly

< c​haser:monero.social > an LLM is not only not a legal entity, it's not an entity at all. people like to hallucinate it is because of their yearnings.

< sech1 > yes, LLMs miss a crucial part of being "alive" which is memory/experience. They forget everything once you relaunch them, they don't learn on your queries - they're a static blob of 0s and 1s. Heck, even if you don't relaunch them, they forget the beginning of the conversation once it doesn't fit in the context window.

< k​ayabanerve:monero.social > PoI had a really interesting scene about this. Great show, one of my favorites.

< k​ayabanerve:monero.social > I won't detail it as it's a minor spoiler but iykyk

< k​ayabanerve:monero.social > https://github.com/kayabaNerve/fcmp-plus-plus/blob/78754718faa21f0a5751fbd30c9495d7f7f5c2b1/crypto/divisors/src/lib.rs#L289-L414 sech1

< k​ayabanerve:monero.social > This is the amount of Rust you need to massively improve ec-divisora

< k​ayabanerve:monero.social > *ec-divisors

< k​ayabanerve:monero.social > That code is a couple hundred thousand iterations per divisor.

< sech1 > "(-F::ONE).to_le_bits().into_iter().take(num_bits_usize).enumerate()" Does Rust force this style of programming?

< sech1 > Functional-like?

< sech1 > Plus it must be a constant in the end, so does the compiler make it "constexpr" (for a lack of better term)?

< sech1 > yeah, I see a lot of micro-optimizations in this code, assuming that compiler is not that smart

< k​ayabanerve:monero.social > That's just a vibe. You can manually say

< k​ayabanerve:monero.social > let neg_one_bits = (-F::ONE).to_le_bits();

< k​ayabanerve:monero.social > for i in 0 .. num_bits_usize {

< k​ayabanerve:monero.social > let b = neg_one_bits[i];

< k​ayabanerve:monero.social > }

< k​ayabanerve:monero.social > It must be constant-time.

< sech1 > this whole "for (i, bit) in (-F::ONE).to_le_bits().into_iter().take(num_bits_usize).enumerate() " can be done at compile time. Or by programmer, if compiler is not capable.

< k​ayabanerve:monero.social > -F::ONE is a constant, sure, but that transform should be cheap and is not available via const fn

< sech1 > I mean the whole for loop

< sech1 > decomposition_of_modulus can be initialized with a constant instead of a loop

< k​ayabanerve:monero.social > (const fn are functions running at compile-time and eligible to calculate constants)

< k​ayabanerve:monero.social > Probably if the APIs exist. F::ONE is a constant. None of the math ops on it are. Traits (bounds on generics) don't have const fns available :/

< k​ayabanerve:monero.social > You'd have to define an extension trait exposing the constant and now we get into more complex Rust

< sech1 > It's always like this. Once you start hunting for performance, all language complexity has to be used.

< sech1 > But this is micro-optimizations, then can be done at the last step (when the algorithms are implemented)

< k​ayabanerve:monero.social > That transform really should be some bit masking and shifts, making it micro, yep.

< sech1 > my C/C++ brain says it must be a memset in the end :D (to initialize decomposition_of_modulus)

< sech1 > NUM_BITS is typically 256 or close to it?

< k​ayabanerve:monero.social > Yep

< sech1 > yeah, for loops over single bits are expensive then

< sech1 > That code asks for a full rewrite

< j​berman:monero.social > Still holding to this: https://libera.monerologs.net/monero-research-lab/20250219#c499558

< j​berman:monero.social > you're looking at the part that's not going to speed up the function by >20%

< sech1 > "can be done at the last step (when the algorithms are implemented)"

< sech1 > Also 256-bit is only 4 64-bit words, so I'm not sure FFT will be faster on such small numbers

< sech1 > FFT is good when multiplying really big numbers

< sech1 > it can be even slower for small numbers

< sech1 > maybe maybe it will be better for 32-bit targets

< k​ayabanerve:matrix.org > sech1: That's a misunderstanding.

< k​ayabanerve:matrix.org > We do polynomial multiplications where the polynomials have 256 256-bit coefficients.

< sech1 > ah, then it's a different story :D

< sech1 > this is FFT territory

< sech1 > I speak in rhymes now :D

< k​ayabanerve:matrix.org > That bit code there is also just nontrivial running time and benefits from a more intelligent design.

< j​berman:monero.social > am I missing something with linking this? this snippet isn't the slow part of prove (unless you're saying that part should be constructed differently so that scalar_mul_divisor is faster?)

< k​ayabanerve:matrix.org > ... that part is a couple seconds IIRC.

< j​berman:monero.social > NO

< j​berman:monero.social > sorry lol

< j​berman:monero.social > no*

< k​ayabanerve:matrix.org > It's 200k iterations per divisor constructed.

< k​ayabanerve:matrix.org > I remember adding an additional loop to avoid branch prediction and runtime going up by seconds.

< k​ayabanerve:matrix.org > I also remember boog900 replaced an O(n3) step with an O(n2) step so it may no longer be so egregious?

< k​ayabanerve:matrix.org > Anyways, feel free to bench it by itself if you don't believe it notable. I believe it's a notable percentage of divisor construction (when defined as scalar, generator -> full divisor).

< k​ayabanerve:matrix.org > That preprocess is an isolate step as it's reusable across generators and we do reuse an instance across generators.

< k​ayabanerve:matrix.org > It was slow enough it was worth reusing.

< k​ayabanerve:matrix.org > I'm not saying it's >50%. Just that it's notable.

< j​berman:monero.social > that part is taking my machine less than 1ms, and scalar_mul_divisor is taking 2s

< k​ayabanerve:matrix.org > Oh, then I may be completely misremembering/remembering the O(n**3) part exclusively.

< k​ayabanerve:matrix.org > (which boog900 removed)

< k​ayabanerve:matrix.org > Apologies if so, glory to the flamegraph

< k​ayabanerve:matrix.org > https://github.com/kayabaNerve/fcmp-plus-plus/blob/develop/crypto/divisors/src/poly.rs

< k​ayabanerve:matrix.org > In that case, this file

< j​berman:monero.social > div_rem is the really slow one. I'll upload a flamegraph for prove in a bit

< k​ayabanerve:matrix.org > Urgh. I recommended wasm32v1-unknown. That means build, tests pass with 1.69 but bench with 1.84. That's wonky.

< k​ayabanerve:matrix.org > (We support platforms which complain with more modern Rusts due to choice of linker. Instead of spending the time correcting cross-compilation, I just bound Rust support to the mutually agreeable 1.69. People should build with a modern Rust, not just for the hell of it, but perf improved by 20% for whatever codegen reasons).

< k​ayabanerve:matrix.org > (wasm32v1-unknown ensures a lack of variables in the binary, as desired for these benchmarks, but is only available on modern Rust)

< j​berman:monero.social > This was the main reason for 1.69 in the first place right? https://github.com/j-berman/monero/blob/23b1b35ba7c7a8e758e1729546b71a9a97291dde/.github/workflows/depends.yml#L98-L100