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

<j​berman:monero.social> I unfortunately won't be able to make today's meeting. Repeating my update from NWLB:

<j​berman:monero.social> All expected tests now pass in fcmp++-stage (we have green CI), shared a TODO list for launch issue tracker ( seraphis-migration/monero #53 ), made serious headway on destroying FFI types correctly thanks to @jeffro256 ( seraphis-migration/monero #39 )

<j​berman:monero.social> Working on finishing that last task, and allowing txs with >8 inputs next. And fixing up current PR's / reviewing jeffro's

<j​effro256:monero.social> Sorry, I also won't be able to make it to the meeting today. Yeah, mainly spent this week on cleanups / fixes / reviewing @j-berman's work

<r​ucknium:monero.social> Meeting time! monero-project/meta #1220

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

<v​tnerd:monero.social> mac hi

<0​xfffc:monero.social> Hi everyone

<a​rticmine:monero.social> Hola

<s​gp_:monero.social> Hello

Hello

<a​ntilt:we2.ee> seas

<d​iego:cypherstack.com> hi

<d​iego:cypherstack.com> us first please, I have to go soon. On vacation.

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

<r​ucknium:monero.social> Diego Salazar: Yes, you will be first

<r​ucknium:monero.social> jberman and jeffro256 gave their updates just before the meeting ^

<b​randon:cypherstack.com> finishing up teh report on divisors

<b​randon:cypherstack.com> have a pre-pre-print for yall which is actionable

<b​randon:cypherstack.com> still has some edits remaining and we need to spend a few days copyediting it before we throw it up on iacr and make it more public, but we can hand off what we have today so MRL can move on it

<r​ucknium:monero.social> me: Working on finishing review of Clover, an alternative to Dandelion++. Also, I modified boog900 's Rust network scanner to get an estimate of the number of reachable nodes that are using the spy nodes ban list: Rucknium/misc-research #5

<0​xfffc:monero.social> ( Last W til yesterday I was off. So I have not an important update right now. I am running late but I will address all the 9933 PR comment before end of this week with new code )

<r​ucknium:monero.social> 3) Divisors for FCMP. [zkSecurity quote for review of Elliptic Curve Divisors for FCMP](hackmd.io/@rotn/HyyFGZcfxl). [Cypher Stack review](github.com/cypherstack/divisor_deep_dive).

<v​tnerd:monero.social> me: more work on subaddress/fees in lws

<d​iego:cypherstack.com> we have something!

<s​gp_:monero.social> Before the zksecurity quote, it would be good to hear from CS about what they worked on last week

<s​gp_:monero.social> Since the outcome of that will determine what we need zksecurity for

<b​randon:cypherstack.com> making a github repo with the doc as we speak

<b​randon:cypherstack.com> merging final conflicts, yada yada

<r​ucknium:monero.social> ....LaTeX refuses to build 😳

<r​ucknium:monero.social> ;)

<b​randon:cypherstack.com> we aren't fully done but the report is actionable enough to send off to yall. we present a protocol as we understand how it SHOULD work, and we show how to use it for schnorr signature verification and bulletproof verification

<d​iego:cypherstack.com> if I may, Brandon, I will quote you from earlier today

<b​randon:cypherstack.com> so if i were to recommend how to use zksecurity to move forward, they should vet our work and check it for correctness and look for mistakes in our proofs

<b​randon:cypherstack.com> sure

<d​iego:cypherstack.com> "We think we have things proven to our satisfaction, we just haven't finished fully computing all the probabilities and computational costs, nor have we fully finished providing examples. However, the vast vast vast majority of the argumentation is done, and i think good."

<d​iego:cypherstack.com> "The final touches will be a bit longer, but at this point we don't have much reason to think the technique is incorrect or unsound fundamentally."

<r​ucknium:monero.social> "Computational costs". Does that mean that the verification time would be much different from what we think it is now?

<d​iego:cypherstack.com> late nights and weekends to get it to this point by this meeting

<r​ucknium:monero.social> Or maybe the proving time?

<s​gp_:monero.social> I assume the proof modifications are documented in the forthcoming tentative report, but can you briefly summarize them and how major you think those changes might be for Monero to adjust to (it's ok if you don't fully know the answer there)

<r​ucknium:monero.social> Thank you Cypher Stack for putting in all this incredible work

<b​randon:cypherstack.com> freeman wrote up a little sage piece of code which will be helpful for assessing these costs

<b​randon:cypherstack.com> So, the short answer is this

<b​randon:cypherstack.com> firstly, the proof modifications required don't seem to impact our asymptotic results, but influence specific constants.

<b​randon:cypherstack.com> we compute a soundness error lower than Bassa's, and I don't fully trust it. But, if Bassa's soundness error is an acceptable upper bound already, then this actually isn't much of a problem.

<b​randon:cypherstack.com> we beat Bassa's completeness error.

<b​randon:cypherstack.com> eagen derived his verification equations by looking at everything as a function of slope and intercept, but by doing so accidentally assumed that everything could be written as rational functions in these parameters. they cannot be, except in edge cases. reparameterizing (begun by Bassa at veridise but not completed) resolves the problem, but due to this mistake, the "chain rule" <clipped messag

<b​randon:cypherstack.com> from calculus was not correctly computed, so verification equations are all much more complicated

<b​randon:cypherstack.com> i'm not sure if that answers your question to your satisfaction sgp_

<b​randon:cypherstack.com> so, at this point, everything seems fine, and we have 40 pages of argumentation and background and proofs to back up the word "seems"

<b​randon:cypherstack.com> moreover, kayaba's divisor witness computation works fine also.

<b​randon:cypherstack.com> so if any further modifications to code are required it is all on the verification side, to make sure that the verification equations being checked actually support the proving system in question

<b​randon:cypherstack.com> we began working out an example of kayaba's "discrete log gadget" which is really a "correct scalar multiplication proving" gadget, but we haven't fully finished that example due to time constraints; future updates to this paper will include it

<s​gp_:monero.social> I don't really have a specific follow up question, but I will schedule some time with kayaba to go through your paper and see where any changes could impact their code, and if so, what that looks like

<r​ucknium:monero.social> Verification equations being much more complicated = CPU verification time would be much longer? Do we know?

<r​ucknium:monero.social> So Eagen neglected the reals, huh?

<b​randon:cypherstack.com> freeman's sage code will help answer that question, but we did not finish our efficiency analysis yet either. all the added costs are "just" computations over the base field, and all muls and adds, no divisions. so we are asymptotically still getting the same advantage as the old verification equations

<f​reeman:cypherstack.com> I'll throw in that adapting Eagen's divisors code to benchmark shouldn't take very long

<b​randon:cypherstack.com> we've been scrambling on the proofs and all the rest was lower priority

<f​reeman:cypherstack.com> For anyone curious gist.github.com/Liam-Eagen/666d0771f4968adccd6087465b8c5bd4

<r​ucknium:monero.social> As I understand it, it is the role of the FCMP Research co-chairs to guide decisions on what to do next. And they are absent this meeting ( kayabanerve and jberman ).

<s​gp_:monero.social> Assuming kayaba can adapt it as expected, your efforts have helped save Monero a _lot_ of time, and saved Monero from choosing a significantly less performant approach

<r​ucknium:monero.social> Or, more importantly, deploying a fatally flawed protocol on mainnet, which could destroy Monero.

<f​reeman:cypherstack.com> For anyone curious, this is Eagen's code that can be adapted for timing gist.github.com/Liam-Eagen/666d0771f4968adccd6087465b8c5bd4

<d​iego:cypherstack.com> yeah yeah, no need to thank us citizens. Just doing our superhero jobs.

<b​randon:cypherstack.com> more review is better

<d​iego:cypherstack.com> Now I'm going to tell Brandon to skedaddle. He was literally up most of the night finishing this up.

<b​randon:cypherstack.com> i would love it if zksecurity scrutinized us

<b​randon:cypherstack.com> i need to finish making the CS github for this though first, diego

<d​iego:cypherstack.com> yes, please use zksecurity to look over our stuff

<s​gp_:monero.social> Yeah, I think that is the best path forward (after kayaba/beman look at it)

<k​ayabanerve:matrix.org> 👋

<s​gp_:monero.social> speak of the devil :)

<r​ucknium:monero.social> I agree that this work by Cypher Stack needs review. zkSecurity can be considered. Would be a good candidate

<k​ayabanerve:matrix.org> If everyone here agrees on zkSecurity performing review being a good idea, then I can be sent the draft for my professional opinion on if we should move forward (so MRL approval now, moving forward later).

<k​ayabanerve:matrix.org> But I haven't seen the draft and can't comment this meeting.

<k​ayabanerve:matrix.org> Alternatively, we just continue having SGP play diplomat and ask to keep the time boxed off and we'll sync again next meeting.

<b​randon:cypherstack.com> it'll be available in the next hour or so

<k​ayabanerve:matrix.org> I won't read it till tomorrow regardless so no worries there

<r​ucknium:monero.social> The timeline on zkSecurity's original quote was:

<r​ucknium:monero.social> > The team will primarily carry out the work during the week of the 23rd of June till 27th of June. We commit to providing the report by the 18th of July; with the additional time allowed to account for protocol / proof updates as necessary and to compile the final report.

<s​gp_:monero.social> I want to get back to zksec this week with an (ideally) final plan for their review time. That should be doable

<r​ucknium:monero.social> hackmd.io/@rotn/HyyFGZcfxl

<r​ucknium:monero.social> So, theoretically, they have the week of June 23 open

<k​ayabanerve:matrix.org> It's just a question on if we want to confirm with committed funding this weekend or next meeting. I'm indifferent. Up to y'all.

<r​ucknium:monero.social> It sounds like the plan is for kayabaNerve to review the next Cypher Stack document, then kayabaNerve, jberman, and sgp can discuss and decide on a plan to approach zkSecurity again

<s​gp_:monero.social> I'll negotiate a different rate since they no longer need to do fixed rate

<s​gp_:monero.social> I'd like to be able to move forward with their approval outside of a meeting, if possible

<r​ucknium:monero.social> I want to say that an approved funds limit should be decided now, but then that gives away MRL's negotiating position 😅

<s​gp_:monero.social> ha

<r​ucknium:monero.social> I could easily see the admin work taking enough time that approval next Wednesday would not add much delay at all. zkSecurity has to read 40 dense pages, then produce a new SoW and quote

<s​gp_:monero.social> it's a matter of keeping the slot at this point

<s​gp_:monero.social> I can try to offer a refundable retainer, idk

<r​ucknium:monero.social> I think it would be OK to go ahead with "approving" the funds before next meeting if the time slot is in danger of disappearing.

<r​ucknium:monero.social> Again, giving away the negotiating position publicly :D

<r​ucknium:monero.social> Or zkSecurity may decide that the direction that Cypher Stack took things is outside of their areas of expertise.

<s​gp_:monero.social> I'll share it publicly when I have the scope updated so people can give their 👍️ or 👎️ publicly

<s​gp_:monero.social> I just prefer not to wait another week if everyone on that committee gives it their 👍️

<r​ucknium:monero.social> Anyone else want to chime in on this decision?

<s​gp_:monero.social> if the proposal sucks we can just skip it

<s​gp_:monero.social> and find someone else

The difficulty of the job dropped considerably now, right?

<s​gp_:monero.social> in theory

Well, if the new approach does not work out, it's back to square 1, but otherwise it's "only" a verification

<b​randon:cypherstack.com> considerably, imo, yes

Still nice to get those people to do it, IMHO

For a bit less, hopefully :)

<b​randon:cypherstack.com> i'm happy to hand off my latex code to them also if it turns out they would rather help fix our document than write their own new one

<r​ucknium:monero.social> I am ok with going forward with a reasonable expenditure for a reasonable scope of work from zkSecurity, before next Wednesday's meeting.

Same

<r​ucknium:monero.social> More discussion on this topic?

<s​gp_:monero.social> I definitely expect to provide them with the CS doc. No more discussion from me

<r​ucknium:monero.social> 4. CCS proposal: Monero Network Simulation Tool. repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589

<r​ucknium:monero.social> This is a proposal from gingeropolous

<r​ucknium:monero.social> It would make Monero usable in the Shadow network simulator. Shadow has been developed for over ten years. Its primary purpose has been to research the Tor network.

<r​ucknium:monero.social> Shadow could be used to test new Monero network code in a realistic setting without trying it on mainnet

<a​ntilt:we2.ee> @rucknium:monero.social i read your R code; are you familiar with Shadow ?

<r​ucknium:monero.social> Not to undermine gingeropolous , but in the interests of the Monero Project, it could be good to get an alternative "quote" from the developer of EthShadow, which made Ethereum nodes compatible with Shadow.

<r​ucknium:monero.social> Which R code did you read? 👀

<r​ucknium:monero.social> I have read a few papers recently that used Shadow to analyze the Tor network.

if all goes well then yes, it would make Monero usable in the shadow network simulator but ginger if "hesitant to list specific milestones. Instead, I request that this CCS be a time-spent based CCS"

<r​ucknium:monero.social> January 29 MRL meeting has my summary of some of those papers

there is also a hardware upgrade element for the MRL machine. a new UPS

<a​ntilt:we2.ee> @rucknium:monero.social peer nodes list draft code

<a​ntilt:we2.ee> i am a bit sceptical; would use R and C++ and test under real world conditions. but I dont know how smart Shadow is...

<r​ucknium:monero.social> Shadow is supposed to give realistic results. You plug actual program binaries into it. That's how I understand it. The advantage is that you can "slow down" the network if the whole network is too burdensome for the CPU to process all at once. And it offer realistic latency on a global scale

I don't have an opinion, because I don't have any idea how something like "Shadow" really works, and what it brings to the table

<r​ucknium:monero.social> I am not sure one way or the other about the need for more storage space in the Monero Computing Cluster. I don't know if I would try to use Shadow to fill up a lot of blockchain space. It could be hard for the I/O to process that many blockchains. On the other hand, the Shadow developers said that the simulation is "paused" during storage read/writes. I mean, it doesn't count the<clipped message

<r​ucknium:monero.social> time spent on those operations.

<r​ucknium:monero.social> Here's a discussion about the pros and cons of Shadow compared to running on "bare metal": github.com/shadow/shadow/discussions/3503

<a​ntilt:we2.ee> IMHO this overhead is not needed for what we are doing with de-doubling

<r​ucknium:monero.social> The discussion was initiated by the EthShadow developer: github.com/shadow/shadow/discussions/3425

<a​ntilt:we2.ee> will read it tomorrow

<r​ucknium:monero.social> Right. I don't think the deduplication would need analysis with Shadow. It is more about major protocol changes. For example, the more efficient tx propagation protocol.

<r​ucknium:monero.social> Or catching potential netsplit behavior like the under-reviewed tx_extra limits

<s​yntheticbird:monero.social> rbrunner, shadow is intercepting network requests of an application so that it can reroute it within its simulated network. You can apply many rules to simulate different situations. This is almost instantaneous and permit you to recreate internet like topologies.

So real Monero daemons, but simulated network?

<s​yntheticbird:monero.social> exactly

I see. Sounds interesting.

<a​ntilt:we2.ee> >Once the basic simulation is functional, I will design scenarios to test specific aspects

<a​ntilt:we2.ee> this is too vague

<r​ucknium:monero.social> Here was my summary of one of the Tor papers that used Shadow: libera.monerologs.net/monero-research-lab/20250129#c491556-c491559

<r​ucknium:monero.social> Jansen & Goldberg (2021) "Once is Never Enough: Foundations for Sound Statistical Inference in Tor Network Experimentation"

<g​ingeropolous:monero.social> im happy to mod the CCS request

<r​ucknium:monero.social> gingeropolous: Thanks for joining. Do you want to respond to some of the comments here?

<0​xfffc:monero.social> I would like to comparison to ns3. and why shadow, instead of ns3

<r​ucknium:monero.social> To get an idea of scale, let's see, the biggest machine has 1TB of RAM. Keeping all node processes in RAM and assuming usual mainnet RAM consumption (I think it's lower for small-blockchain nets like testnet), that would be about 500 nodes on the Shadow network.

<0​xfffc:monero.social> I had this idea of simulating monero under realworld network simulator for long time under ns3. But never had a time to implement it. I use this to run 100s of nodes locally and do simple benchmarks though: github.com/0xFFFC0000/benchmark-project which was very successful.

<g​ingeropolous:monero.social> yeah sorry im late. tryin to see things need responding... i could go either way on additional storage, i just didn't want it to block progress.

<0​xfffc:monero.social> I run 128 node here: github.com/0xFFFC0000/benchmark-project

<r​ucknium:monero.social> However, the EthShadow developer reported github.com/shadow/shadow/discussions/2622

<r​ucknium:monero.social> > "I tried using `--use-memory-manager=false` already. It works for me. I can run 5,000 gossipsub nodes with an 8GB machine with 96GB of swap space used. Thank you.

<g​ingeropolous:monero.social> nice.

<a​ntilt:we2.ee> @0xfffc did you test-run #9933 - what are your first impressions ?

<g​ingeropolous:monero.social> re: scenarios, i can get more specific.

<0​xfffc:monero.social> Yes, I ran test for 9933. I can get into deeper information about this, before that need to fix something upstream. The numbers and information will be disclosed.

<0​xfffc:monero.social> Next week, You have my promise I will have more info about that :)

<g​ingeropolous:monero.social> re: ns3, i'll be honest I hadn't come across it. But my backwards rationale would be that there already exists a cryptocurrency network impl of shadow, so we know it works. but that also holds true for ns3 now b/c of your work. so....

<0​xfffc:monero.social> I like how shadow operates. I think this can be very helpful CCS. For next step maybe we tried ns3. who knows. ns3 I believe would provide much tighter control over anything. but the cost would be it is much harder to get something like that running.

<a​ntilt:we2.ee> @0xfffc:monero.social i am interested in comparing white + gray_lists... how would spy nodes respond ?

<0​xfffc:monero.social> on 9933? or on ns3 simulation?

<r​ucknium:monero.social> This recent paper (March 2025) uses Shadow instead of ns-3 and gives reasons: arxiv.org/abs/2503.04810

<a​ntilt:we2.ee> #9933

<r​ucknium:monero.social> On page 8 to 10

<r​ucknium:monero.social> 9 to 10

<r​ucknium:monero.social> I mean

<0​xfffc:monero.social> Interesting paper. I am reading it right now

<0​xfffc:monero.social> They have low level requirement which they cannot implement in ns-3 runtime env. This does not apply to monero AFAICT . I am not saying we should definitely use ns-3. But we should be aware of the options.

<0​xfffc:monero.social> I will have more info about this in next meeting. 🤝

<0​xfffc:monero.social> ( my apologies for delay )

<a​ntilt:we2.ee> Shadow needs to be "trained" in how spy nodes would likely react... just to make a point that real world is hard to predict. We would need to compile spy nodes to create such a game-like scenario

<r​ucknium:monero.social> Seems like there is opportunity for more discussion of the Shadow CCS, especially after more people have time to review materials and think about requirements.

<g​ingeropolous:monero.social> oh yeah. there is a lot of ancillary work for the simulations. like, rate of transaction creation... where do we get realist numbers. probably statistics from node data seeing txs come in, with some math stats regarding how many nodes the txs likely came from. etc

<0​xfffc:monero.social> The idea is a positive move forward IMHO.

<g​ingeropolous:monero.social> node types: exchanges nodes. pool nodes. user types. Ultimately I'd love there to be a web-gui (or some other means) such that anyone in MRC (or extended) could submit a simulation

<0​xfffc:monero.social> Yes, you are basically simulating a real world. So everything goes here

<r​ucknium:monero.social> 5. Subnet deduplication in peer selection algorithm to avoid spy nodes. [Draft research bulletin](github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf), [implementation PR](monero-project/monero #9939).

<r​ucknium:monero.social> Like I said in my update, I modified boog900 's Rust network scanner to collect the peer lists that nodes share when you do the initial Levin protocol handshake: Rucknium/misc-research #5

<r​ucknium:monero.social> And I have results: I estimate that 6 percent of reachable nodes (i.e. nodes with open ports) are running with the spy node ban list.

<r​ucknium:monero.social> Not bad. Not great. Within my expectations.

Hmm. I would have estimated higher.

But very good to have hard numbers.

<r​ucknium:monero.social> Nodes share 250 random IP addresses from their white_lists. So, if zero IP addresses from the spy node ban list are shared, with high probability the node is using the ban list.

<r​ucknium:monero.social> To estimate the number of unreachable nodes using the ban list would be more difficult and take longer, since you have to passively wait for them to connect t you.

<a​ntilt:we2.ee> hopefully @jeffro256:monero.social will review #9939 soon :)

<r​ucknium:monero.social> I spot-checked the results for nodes that are known (or claim) to be using the spy node ban list, e.g. Cake Wallet's nodes.

<r​ucknium:monero.social> And the spot checks looked correct

in my peer list there are approx 60-100 nodes who still relay mordinals at any given time

Lol. How would you even know that :)

<r​ucknium:monero.social> plowsof: You mean, would accept a too-large tx_extra tx?

correct, rbrunner i ask them "did you update yet lol?" (invalid transaction hex iirc) and their json error response contains the "new" key for being too large true/false

<r​ucknium:monero.social> plowsof helped me with a problem I was having with this 6 percent estimate, by the way. Helpful in the shadows as always.

Ok

if seed node operators all added this ban list would that help? or do clients then query the other peers in the provided list?

<a​ntilt:we2.ee> would help most definitely

I don't think it would help much, at least not in the short term. The IP numbers of the spy nodes are stored all over the place.

<r​ucknium:monero.social> plowsof: I think it would help temporarily, but eventually older nodes would just cycle through their peer lists. I think.

<a​ntilt:we2.ee> gray_list spamming is too easy right now

i see, thank you

<r​ucknium:monero.social> IIRC, newborn nodes syncing the blockchain from scratch query the seed nodes. Old nodes only query them as a last resort when they cannot connect to anyone.

I remember the same, yes.

Testnet sometime ran without any working seed nodes for quite some stretches of time

<a​ntilt:we2.ee> there is also a fall back mechanism iirc - what Gao et. al would use for a potential eclipse attack

<r​ucknium:monero.social> 6. Web-of-Trust for node peer selection.

<a​ntilt:we2.ee> @Ruckrunium could we plz rename item: "Web-of-Trust for node peer selection" -> "Peer Scoring Metrics" ?

<a​ntilt:we2.ee> would be more descriptive of what we are trying to do right now.

<a​ntilt:we2.ee> #9933 and #9939 are on the way. Thats perfect already IMHO

<r​ucknium:monero.social> Sure. I can do that

<r​ucknium:monero.social> Anything more on this topic for now?

<a​ntilt:we2.ee> I'd like to get an overview on the "anchor node" code as implemented right now. I can do that if no one has done it before

<r​ucknium:monero.social> I would also like to know what the anchor peer behavior is

<r​ucknium:monero.social> For now we shall be kept in suspense.

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<a​rticmine:monero.social> Thanks

<s​yntheticbird:monero.social> chat is this real: x.com/MoneroResearchL

<c​haser:monero.social> official logo, most officially looking handle possible, but it's unofficial. yeah.

<3​21bob321:monero.social> Wonder who created the account

<s​yntheticbird:monero.social> thx anon

<3​21bob321:monero.social> Hope it's not the same person for @ monero