<rucknium> MRL meeting in this room in two hours.

<rucknium> Meeting time! monero-project/meta #1466

<vtnerd> hi

<rucknium> 1. Greetings

<jberman> waves

Hello

Hi

hi

<jpk68:matrix.org> Hello

<jeffro256> Howdy

<gingeropolous> howdy doo

<rucknium> 2. Updates. What is everyone working on?

<sgp_> Hello

<rucknium> me: Analyzing defenses against Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (arxiv.org/pdf/2609.10260)

<jeffro256> me: The version compatability testing framework, prepping beta v3 stressnet, working through FCMP++/Carrot bug reports

<jberman> me: we released beta stressnet v3, and I opened all PR's for Phase 3 of the FCMP++ integration audit which includes all code necessary to verify FCMP++ txs at consensus to prevent inflation. Here is the final consensus verification integration PR: monero-project/monero #11440

<vtnerd> me: some lws bugs, going to finish updating the ssl patch today, and then making sure all of the lws+lwsf fcmp++ changes are ready

a look at the monero network. as i host 3 seed nodes a small window of unreachable nodes are found - from this an estimation of the entire network is made which gets better over time. observer.monerodevs.org

<gingeropolous> me: native mining in monerosim evolving into selfish mining experiments and mitigations, and trying to build a stressnet data capture apparatus.

an active peer list poisoning is observed coming from Peg Tech

<jpk68:matrix.org> Me: finishing up the I2P SAM integration work

<rucknium> 3. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed). FCMP++ Integration Audit Overview (seraphis-migration/monero #294). Network upgrade [... too long, see mrelay.p2pool.observer/e/wuem5q8LdGZjUU9U ]

<jberman> On upstream FCMP++ integration, repeating from above I opened all PR's for Phase 3 of the FCMP++ integration audit which includes all code necessary to verify FCMP++ txs at consensus to prevent inflation. Here is the final consensus verification integration PR: monero-project/monero #11440

<jberman> Next I'll write up a draft to include in a request for quotes on audit phases 2 & 3, as proposed by @sgp_:monero.social last week

<jeffro256> Is tobtoht back yet?

<jeffro256> Still waiting on mx25519 issues to resolve as a prereq to carrot_core.

<jberman> To be clear, phase 2 integration PR's have already been merged. Phase 3 PR's are now open for review as linked above. It's my opinion we can proceed with reviews (and merges) today in parallel to the audits

Is the request for quotes process (audit phases 2 & 3) currently live and if so, how does participation in that normally look like?

<vtnerd> I think the mx25519 pr is ready, was there something else?

<jeffro256> Licensing

<jberman> MarkoPohlo: It's not currently live. We ( @sgp_:monero.social ) sends out emails to different firms with information on scope and requests a quote, then we discuss quotes received in here and settle on a candidate

<sgp_> MarkoPohlo: no it is not yet live. Sign up for the RFQ newsletter here to be notified: listmonk.magicgrants.org/subscription/form

Appreciate the explanation, we (Runtime Verification) would love the chance to participate in the process.

<sgp_> You are welcome to, and I am excited to receive your proposal

<jberman> On Research audit items: Least Authority privately shared their final report on helioselene (still looking it over internally), and is also the firm we're slated to kick off the 2nd round of audits on the cirtcuit and gadgets impl & 1st round on fcmp-plus-plus lib

<jberman> UkoeHB is rebasing the FCMP++ & Carrot multisig impl onto the latest fcmp++-stage development branch. That's a major feature item on the TODO list

<jberman> I'd say our likely biggest bottleneck going forward is getting code merged upstream. So, requesting reviews on the FCMP++ integration PR's linked here to get that going: monero-project/monero #11440

<jberman> that's all from me

<rucknium> Thank you. Anything else on this topic from anyone?

<rucknium> (stressnet is next)

<rucknium> 4. FCMP beta stressnet (github.com/seraphis-migration/monero/releases). Version 3 launch checklist (seraphis-migration/monero #415).

<jeffro256> Beta v3 is released!

<jberman> you can download the software to participate here: github.com/seraphis-migration/monero/releases

<jeffro256> v17 fork is at height 3102800

<gingeropolous> im trying to organize data capture and measurement effort

<gingeropolous> seraphis-migration/monero #495 - please comment

<rucknium> How much is the bot borrowing from my github.com/Rucknium/monerod-monitor ? :D

<gingeropolous> i didn't point it at it. But that just seems to be for an individual's node?

<rucknium> Isn't your prpoposal also for an individual's node?

<gingeropolous> yes, but it will push data to a central data collector, and log the generation of txs from the spam generator (on the MRC), etc.

<rucknium> Anyway, not very important. I notice the issue says that the data will be in an R-compatible format. That's good. Well, most data formats are R-compatible because there are packages to read everything.

<rucknium> The UI part of my monitor is very slow. I'm not happy about that.

<rucknium> Anything more on stressnet?

<jberman> nothing from me

<jeffro256> I'm done

<rucknium> 5. Relative locks with FCMP++ (monero-project/research-lab #161).

<rucknium> Any discussion of this item?

<rucknium> Should I take this item off the agenda until someone brings it up again?

<jberman> sure

<rucknium> 6. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (arxiv.org/pdf/2609.10260)

<rucknium> I have some graphs for you! AFAIK, IRC side can get links to images. Let me know if IRC can't see the images and I will post them somewhere on the web.

<rucknium> I've run monerosim simulations. They are 26 hour runs. 1,200 honest monerodnodes and 1,000 adversary "nodes" (actually just lightweight py-levin processes). I set the "burn in" time to 14 hours so honest nodes have time to find each other and fill their peer lists. Then the adversary attacks for 12 hours. All the honest nodes are reachable except for one, the "target" unreachable node.

<rucknium> In theory, all unreachable nodes should be affected the same way. We just don't have more because running more nodes will start to exhaust machine RAM.

<rucknium> One simulation has all honest nodes running the v0.18.5.1-release. The other has them running v0.18.5.1-release, modified by my proposed patch: gist.github.com/Rucknium/fd57fd99fc9bc985d671a6ce96cc668e

<rucknium> I will explain the purpose of the patch after a few graphs. First, the big result.

<rucknium> By the way, this is preliminary findings. I will need to double-check everything to make sure there are no issues.

<rucknium> mrelay.p2pool.observer/m/monero.social/aegJQTnYiWoiwUqahUTdjkPN.png (outbound_adversaries_unreachable.png)

DataHoarders bridge is working , IRC can see the images

<rucknium> This graph shows that the adversary can nearly eclipse the unreachable node running the unmodified v0.18.5.1, occupying 11 of 12 outbound connections. My proposed patch defeats the attack.

<rucknium> Thanks for checking, plowsof

<rucknium> How does the attack work? First, the adversary peers poison the white_list of the reachable nodes.

<rucknium> mrelay.p2pool.observer/m/monero.social/XfXqdmLKCYkFSqJrBLglvfhJ.png (white_list_reachable.png)

<rucknium> When the attack launches in the status quo network (top plot), the adversary peers push the honest peers out of the reachable nodes' white lists because there are only 1,000 slots in the white list.

<rucknium> When a new peer is inserted into the white-list that would take it beyond its size limit, the honest node drops the "oldest"-seen peer from the white_list

<rucknium> On the bottom you see that no honest peers are dropped. I will come back to that.

<rucknium> The honest reachable nodes then infect the unreachable nodes' peer lists. Unreachable nodes get their peer lists from reachable nodes. So the unreachable nodes keep asking the reachable nodes for their now-poisoned whitelists.

<rucknium> mrelay.p2pool.observer/m/monero.social/CUGFPEpOKquQQCGJkoVHByQM.png (white_list_unreachable.png)

<rucknium> In the top plot there you'll see that by the end of the simulation, the honest unreachable nodes still have a majority of their white_list occupied by honest reachable peers. So why do they get eclipsed?

<rucknium> IMHO, it's a product of some "interesting" design decisions in the connection selection logic.

<rucknium> Those decisions are why just increasing the white_list size limit is not enough.

<rucknium> The next image has a violin plot (en.wikipedia.org/wiki/Violin_plot). It's a distribution density plot turned on its side.

<rucknium> mrelay.p2pool.observer/m/monero.social/sPaYzhxriRWIiShryOZQoLeG.png (peerlist_draws_reachable_status_quo.png)

<rucknium> This shows from where nodes are selecting their next connection. Every 101 seconds, a node will drop one of theour outbound connections and choose one to replace it.

<rucknium> There's a lot going on in this graph.

<rucknium> The top part shows the position, ordered by last_seen where the node selects its next connection from the white_list

<rucknium> The vertical axis is in log scale

<vtnerd> doesn’t this diff you sent change the bootstrap process? or I guess the idea is just wait until the graylist housekeeping runs?

<rucknium> Usually, the node selects from very recently-seen peers as its next connection.

<vtnerd> because theres now a bias towards whitelist, which I guess is needed given your results

Peg Tech are currently flooding gray lists (800~ips with many ports totalling 4k~ entries circulating. its a proxy network known for facilitating ddos attacks (qurium.org/alerts/denial-of-service…ced-to-yet-another-proxy-provider-2)

<rucknium> Exactly.

<rucknium> ^ Look carefully at the slope of the honest.peers line in the two scenarios. The honest nodes' white_lists fill more slowly with my patch. > <@rucknium> mrelay.p2pool.observer/m/monero.social/XfXqdmLKCYkFSqJrBLglvfhJ.png (white_list_reachable.png)

<rucknium> AFAIK, there are three ways a peer gets into the white_list:

<rucknium> 1. A reachable node connects to me

<rucknium> 2. I perform gray_list housekeeping (promotes a reachable node to the white_list, but doesn't establish a connection)

<rucknium> 3. Directly promotes a peer from gray_list to white list when selecting from gray_list for the next connection.

<rucknium> My patch reduces the probability that (3) happens, so the white_list filling is slower, but not too slow IMHO.

<jeffro256> Does the patch touch the quadratic probability distribution used to pick very recent white list peers ?

<rucknium> The status quo logic first tries to connect to a gray list peer. If there are 3 failures, then it tried the white list up to three times.

<rucknium> @jeffro256: Yes. It gets rid of it

<rucknium> "Mister Chesterton, tear down this fence."

<jeffro256> Cool, I always thought that it was a bad idea

<jeffro256> Even without active attackers, it felt centalizing

<jeffro256> But I never deep dived into it

That survived the last peer selection code update, from me and Rucknium :)

Maybe now its days are numbered

<rucknium> My patch simplified the logic a lot. It eliminates the "quadratic" recent distribution and does not have a split logic flow when the node has greater than or less than 8 outbound connections.

<rucknium> I didn't want to touch that logic in the /24 subnet deduplication PR because of the Chesterton Fence logic. But it's a clear danger now.

peer list spammers are being tracked currently at observer.monerodevs.org

<rucknium> Biasing your connection selection to pull from the gray list gives the adversary an advantage because the gray list can be dominated and manipulated by adversaries more easily than the white list.

<rucknium> So I decided to first pull from the white list instead

<rucknium> And selecting only recently-seen peers from the white list makes it difficult to get out of the clutches of an adversary if you find yourself there.

<rucknium> mrelay.p2pool.observer/m/monero.social/RFoBnDUkiflymxjjeHaxIpGz.png (peerlist_draws_reachable_defense.png)

<rucknium> This is that same graph, but with the proposed defense patch. Almost no draws from the gray list. And the draws from the white list are spread uniformly (note the log vertical scale on the top plot).

<rucknium> I don't have these graphs for the unreachable node because monerosim didn't save the info. (need to fix that). But the logic is there.

<gingeropolous> blargh

<rucknium> My patch ( gist.github.com/Rucknium/fd57fd99fc9bc985d671a6ce96cc668e ) has 3 reforms:

<rucknium> 1. Increase the white_list limit to 10,000 so adversary peers cannot push out honest peers

<rucknium> 2. Try to draw from the white_list first instead of the gray_list

<rucknium> 3. When drawing from the white_list, select in a uniform random manner from the whole white_list instead of just recently-seen peers.

<rucknium> 10,000 is arbitrary, but I have an idea of how to decide a not-arbitrary limit. Not sure if it makes sense to go into that detail here.

<rucknium> IMHO, the Nyx eclipse attack is a serious concern. I would support putting a defense patch into the next monerod release.

<rucknium> More defenses can be put in there, but just these changes mostly defeat the attack.

<rucknium> Discussion? Questions?

<jeffro256> If we could get a ground truth value for the number of reachable nodes IRL, I think setting the whitelist limit to approximately that value would make the most sense. But that's just me spit balling > <@rucknium> 10,000 is arbitrary, but I have an idea of how to decide a not-arbitrary limit. Not sure if it makes sense to go into that detail here.

<rucknium> By the way, I tried subsets of the reforms in monerosim, but I needed all three to get the proper defense.

<vtnerd> my only concern is that this doesn’t distribute the load properly, because it no longer aggressively selects from graylist. otoh, there’s already a routine to move nodes into whitelist

No question, but just have to say I admire your work

<vtnerd> the recently seen bias is likely a good change

ive observed 4-3k reachable the past few days

<rucknium> Thanks. Couldn't have done it without @gingeropolous:monero.social 's work on monerosim. Or Shi et al. for raising the issue.

Yes, it's really nice how sometimes everything flows together nicely

<rucknium> @vtnerd:monero.social: IMHO, it would be a good idea to mathematically formalize the peerlist system. Once formalized, one could try to prove that the system has some properties. Hopefully, good security properies.

Doesn't this diminish the importance of the grey list quite a bit?

<rucknium> There is a flow of addresses around the network, from reachable to unreachable, from new to old. How does that happen? It could be formalized IMHO.

<jeffro256> Have you looked into simulating new attacker models for which the proposed defense would do worse?

<rucknium> Yes, but graylist is where "There be dragons"

I see.

<rucknium> @jeffro256:monero.social: No. The weakness in the analysis is that the attacker's strategy is the same for both scenarios.

<rucknium> But some of Shi et al.'s suggestions were incorporated into my defense.

<rucknium> Since at least early last year, the Shi et al. research team has suggested that white list limit be raised.

<rucknium> Graylist should be untrusted because nothing there is verified (potential addresses there are put into the white_list when verified). And adversaries can push up to 250 new addresses there per Levin handshake.

<rucknium> By "verified" I mean check that there is actually a reachable node at that address:port.

<vtnerd> yeah Im liking the change more. that flipped logic to pull from graylist is funky. wish we had someone to describe the reasoning (assuming there was any)

<vtnerd> presumably it was done to prevent concentration amongst a small number of peers, but the other logic to prefer recently connected suggests against that

<rucknium> When rburnner and I looked at it last year, it was interesting to me that the logic pulled in two different directions with respect to "recent" peers. I thought maybe it was OK like it is, because it was "balanced".

<rucknium> But in the end it was vulnerable.

<rucknium> I'm going to ping @boog900:monero.social in case he wants to comment.

<rucknium> My next step is to make a PR with the patch and the analysis I explained here. The full patch will remove dead logic, too.

<vtnerd> the logic appears changed in this patch anyway monero-project/monero b750fb2#diff-85f0577b849d28c11a899cb863aec3df1d946e0bb214a623deef05928271fef6

<vtnerd> I believe the original logic was to attempt one whitelist, then grey each time

<vtnerd> whereas this add the while loop

<vtnerd> the original code may have been worse actually

<rucknium> Anything else on this topic for now?

<rucknium> We can end the meeting here. Thanks everyone.

<ofrnxmr> Thanks ruck