Meeting summary: Monero Research Lab, 19 February 2025

Posted Thu, 20 Feb 2025, from Monero Observer

Price Analysis

Source Article Link: https://monero.observer/meeting-log-summary-monero-research-lab-meeting-19-february-2025/

This is a comprehensive summary, with added reference links, of the MRL meeting1 from February 19th 2025, 1700 UTC.

Logs

The raw, unedited, full log file for this meeting:

250219-mrl.log (168 lines)

Summary

Note: it is possible that some relevant information may be missing from this summary; read the full log file for the complete, unedited discussion.

  • Participants: 8 (rucknium2, c​haser3, s​yntheticbird4, rbrunner5, s​agewilder6, j​berman7, j​effro2568, k​ayabanerve9)

  • (1) Updates

    • rucknium was learning Rust and doing some more analysis of subnet deduplication peer selection against spy nodes10, while preparing all OSPEAD-related documents and code11 for public release (expected Febuary 20)

    • j​berman managed to get FCMP++ txs validating at consensus12 and was now working on re-reviewing jeffro256’s blockchain sync PR #913513; he also announced that the FCMP++ optimization competition14 details are now ready for preliminary review

    • j​effro256 was working on debugging release issues and review15

    • rucknium reminded participants that anyone can suggest MRL agenda items, noting that: I have been composing the agenda based on my own judgement recently

  • (2) Open discussions

    • (2.1) on the ‘Prize contest to optimize some FCMP cryptography code’14:

      • j​berman shared a list of the main things he did during the previous week: a) settled on a method of scoring helioselene, weighting specific arithmetic operations as a % of the final score, b) fixed an issue in the wasm-cycles counter used to check for constant time, and c) updated the README’s

        • rbrunner wondered how hard it will be to achieve constant time execution for the submitted code and whether people may overlook that requirement and then stumble over it

          • j​berman suggested looking at how the current reference code uses ops like ct_eq and conditional_select to achieve constant time and noted that kayabanerve previously mentioned it would be relatively trivial to speed up the code by like 300% if non-constant time code was allowed; then underlined that it is an important requirement that he should highlight more significantly

            • rucknium was curious why the constant-time is so important in this application

            • syntheticbird thought that constant-time is only useful for construction and nodes that only proceed to verification don’t need it

            • s​yntheticbird pointed out the attractiveness of advocating for two separate implementations - one for proving that is constant-time, and one for verifying that is variable time - if what kayabanerve stated is true

            • j​berman clarified that constant time isn’t necessary for verifying and the 300% figure was for ec-divisors prove; he also shared that kayabanerve has explicitly expressed a lack of interest in maintaining/reviewing multiple implementations

            • k​ayabanerve commented that Non-constant-time means leaked private keys and no privacy under side-channel attacks and stressed - in agreement with what jberman stated - that the 300% comment was for proving, not for node operations

        • r​ucknium shared a statement made by kayabanerve on the issue the previous week: 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.

          • s​yntheticbird and rbrunner half-jokingly hinted at potential issues with the contest by mentioning the fact that kaybanerve created the contest, abandoned it, then ultimately decided to participate only after it was picked up by someone else

            • rucknium agreed that there are some ethics issues involved that need to be discussed - specifically self-dealing - although it was unclear if those were important enough to bar kayabanerve from participating in the contest

              • chaser wondered if the specific issue was Kayaba raising the funds, writing the code, and then entering the contest to improve the code and winning part the funds he raised; rucknium explained that setting the contest rules - Which writing the code in the first place is part of was a particular worry

            • s​yntheticbird recommended some delay between the announcement of the contest and opening the contest

              • j​berman agreed: announcement first, delay, then contest opens

            • kayabanerve stated that if there are sufficient ethical concerns he will drop out, noting that 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.

              • j​berman shared some figures: 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 pointed out that currently the loose consensus appears to be to allow kayabanerve to participate in the contest

              • kayabanerve was keen to underline that his interest in the contest isn’t due to free time or personal love for the subject and stated that he would be ready to accept 1m/y to operate the contest, and not participate accordingly, for the time spent working on the contest: I believe the current code is fine. It just got bumped up to a very large $ figure after I dropped it.

                • j​berman noted that the bump was only due to discussions that weren’t accurately taking into consideration expected time to complete the work and clarified that it was brought down again after taking your prior estimate into consideration

                • k​ayabanerve replied: And like magic, I’ve lost interest and will go find other places to pay my bills

      • sech1 was unsatisfied with the competition being Rust-only, which cuts a lot of devs, including me

        • s​yntheticbird noted that it is never too late to learn Rust and also suggested trying to team up with a Crab master and he will translate your improvements

        • j​berman pointed out that rust is really not that hard to learn and thought the core of this competition will be implementing faster algorithms, not necessarily niche micro-optimizations that are language specific

        • kayabanerve did not believe that Rust, at this level of programming, should be a blocker, given that 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.

    • (2.2) on ‘FCMP research progress status’16:

      • r​ucknium asked participants if there is anything we can be doing now to prepare for the next steps of protocol proving and code auditing

      • j​berman noted that Veridise is making solid progress on their leg of EC divisors R1CS but had no updates on CS progress yet; he suggested bringing in a new 3rd party to start on some impl audits

      • chaser wondered if both audits started yet; jberman confirmed Veridise started but was unsure of CS

    • (2.3) on ‘Fluffy blocks efficiency improvements’17:

      • rucknium shared that jeffro256 was looking into this topic

      • c​haser was looking for a link to get a better meta on the fluffy blocks improvements topic; rucknium noted that it is very early stages

      • j​effro256 thought that PR #913518 will probably get merged with relaying empty blocks at first although it would be nice to know if the scheme of relaying transactions you didn’t know about doesn’t leak information

        • jberman was ok with relaying empty blocks but wanted to re-review that full flow of requesting missing / responding

        • r​ucknium thought that there could be a small info leak and offered to 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


Let me know if you find this kind of report helpful.

Feedback, edits always welcome @/about.

-3RA

  1. /monero-research-lab-meeting-19-february-2025/ ↩

  2. https://github.com/Rucknium/ ↩

  3. @chaser:monero.social ↩

  4. https://github.com/SyntheticBird45/ ↩

  5. https://github.com/rbrunner7/ ↩

  6. @s​agewilder:unredacted.org ↩

  7. https://github.com/j-berman/ ↩

  8. https://github.com/j​effro256/ ↩

  9. https://github.com/kayabaNerve/ ↩

  10. https://github.com/Rucknium/misc-research/commit/3fe27b56a57a8306b25537e260c43ac9ba429a40 ↩

  11. https://github.com/Rucknium/OSPEAD ↩

  12. https://github.com/j-berman/monero/commit/b5b149269a544e7c9eb8f076e1fac4f4a3e92a9f ↩

  13. https://github.com/monero-project/monero/pull/9135 ↩

  14. https://github.com/j-berman/fcmp-plus-plus-optimization-competition ↩ ↩2

  15. https://github.com/jeffro256/monero/commits/misc_hf17_rules/ ↩

  16. https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/ ↩

  17. https://www.getmonero.org/resources/moneropedia/fluffyblocks.html ↩

  18. https://github.com/monero-project/monero/pull/9135#discussion_r1957451272 ↩

License: CC BY 4.0, no changes were made to the article.