<midipoet:matrix.org> Thanks for sharing that info.

<ack-j:matrix.org> @rucknium:monero.social: the author of “An Analysis of Monero’s Network Topology” is planning to join our meeting today @jkirsch10:matrix.org

<rucknium> @ack-j:matrix.org: Thank you. I've added it as first agenda item today.

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

<tnzx-dev:matrix.org> thx

<gingeropolous> did we ever get the full text for that available somewhere?

<rucknium> @gingeropolous:monero.social: ^ > <@dnvie:matrix.org> mrelay.p2pool.observer/m/matrix.org/EpMUiRMeAYtAsffoycyvRyvM.pdf (An_Analysis_of_Moneros_Network_Topology.pdf)

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

<rucknium> 1. Greetings

<vtnerd> hi

<sgp_> Hello

Hello

<ack-j:matrix.org> Hi

<boog900> hi

<jeffro256> Howdy

<jberman> waves

<articmine> Hi

<gingeropolous> hi

<redsh4de:matrix.org> hi

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

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

<jberman> me: FCMP++/Carrot rebase in prep for beta v3 + preparing final beta v3 items

<jpk68:matrix.org> Hello

<gingeropolous> <-- working on monerosim. native mining is working, started exploring selfish mining. All of the published things have been replicated, and its currently exploring mitigations. Also launch an effort to create a model network (a replica) of mainnet in monerosim based on published topology research. Also dreaming of hardware upgrades as these sims push things to the limit

<vtnerd> me: put ssl on backburner (still undecided on how to handle async code), a few housekeeping things / bug fixes across monerod/lws, and lastly working on tightening up the encryption/recovery process for lwsf (and possibly wallet2). More is possible with Carrot, as it doesn’t use the seed directly for spend key

<ack-j:matrix.org> Me: finally finished my PR to the monero block explorer to add k-anonymous transaction lookups. I also created a rust monerod block explorer that works over rpc. github.com/xmrack/oxblocks

<jeffro256> me: added K^j_v rebind changes to spec, finished first commit of the version compatibility test framework github.com/jeffro256/monero-compat, working with j-berman on FCMP++/Carrot rebase and v3 prep and debugging

<ack-j:matrix.org> Magic: we have contracted Adalogics to start the second fuzzing proposal in October

<rucknium> Is @jkirsch10:matrix.org here?

<jkirsch10:matrix.org> Hi yes I'm here

<rucknium> 3. Kirschner (2026) “An Analysis of Monero’s Network Topology” (ieeexplore.ieee.org/abstract/document/11676613)

<rucknium> @jkirsch10:matrix.org: Welcome!

<rucknium> Thank you for joining us. Do you want to briefly explain your paper?

<jkirsch10:matrix.org> Hi yes thank you

<jkirsch10:matrix.org> The goal of the paper was to characterize some basic network-level (as opposed to node-level) features of the network. The methodology aimed to be relatively passive, i.e. using monero protocol itself. The primary goal is discovering as many active nodes as possible. Then some very basic analysis is done regarding network conc [... too long, see mrelay.p2pool.observer/e/zvaDxq0LdTRNeEZh ]

<jkirsch10:matrix.org> The primary characteristic finding of the paper is the high concentration of proportion of netwrok edges in a relatively small proportion of network nodes, and that these edges are not network community specific. Thus routing attack could have big effect. Again without further analysis this finding or rather its impact warrants skepticism

<rucknium> Thanks. When did you finish writing this paper?

<jkirsch10:matrix.org> Yes very important. In terms of the numbers presented, (due to lengthy research/publishing process) the experiments in the paper are 2 years old and experiments should be run again to get updated figures

<rucknium> That makes sense. I noticed that the most recent reference was 2022. You have some fact that are out of date.

<rucknium> For example, you said that the default number of outbound connections is 8. It was raised to 12 in 2020: monero-project/monero c67fa32

<jkirsch10:matrix.org> Agreed and thus basic protocol info given to reader are old

<jkirsch10:matrix.org> yes exactly

<jeffro256> Some big changes were made to outgoing connection selection to avoid spy node centralization. Specifically, it weights all IPs in a /24 subnet as "one choice" instead of N choices. Do you think that this would make a large impact to the findings?

<rucknium> And there is this paper from 2025 that is very relevant: moneroresearch.info/278 Gao, Y., Zhang, Y., Piškorec, M., & Tessone, C. J. (2025). Monero Peer-to-peer Network Topology Analysis.

<jkirsch10:matrix.org> @jeffro256 It would make some impact on the findings although not a large one. For example main finding regarding node-edge concentration included a few /24 prefixes but not many. I don't have the exact number on hand, i think 4

<ack-j:matrix.org> @jkirsch10:matrix.org: have you analyzed other decentralized cryptocurrency networks in the past or since this paper?

<jkirsch10:matrix.org> No I have not

<rucknium> I don't agree with some of your interpretations of the data in here, but I will try not to eat up time here with that. I was surprised that you said "These nodes provide a peer list to other nodes that is larger than the maximum white list size of 1,000." That's interesting. I haven't noticed that in my network scans, but I have not checked that closely yet.

<jeffro256> I wonder if LinkingLion was active in 2022... They were over 50% of reachable public nodes at some point, but IDK about in 2022

<boog900> @rucknium: I think that would get the peer dropped IIRC

<jkirsch10:matrix.org> I completely admit that some of the interpretations of the data may be up to debate as I am certainly not an expert. Yes that was a main interesting finding and again although sending such a large peer list was not part of the protocol at the time perhaps maybe there have been protocol changes since the paper that either intentionally or "accidentally" prevent such "abuse"

<boog900> github.com/monero-project/monero/bl…f48fea81/src/p2p/net_node.inl#L2349

<boog900> 250 is the max

So 1000 for the whole list, and adding 250 max in a single go?

<jkirsch10:matrix.org> Ah, yes. At the time I did indeed passively form peer connections with them. Any node in the paper that was on any peer list yet I wasn't able to connect to was not included in the analsysis

<jkirsch10:matrix.org> Sorry. i should say any node that was discovered, not "in the paper", if i wasn't able to connect, it is not in the paper and not in the data

<boog900> rbrunner: yeah

<rucknium> @jkirsch10:matrix.org: Here is data from my network scanner, by the way: xmrnetscan.redteam.cash

<rucknium> You say in the paper that no one except MoneroHash monitors the network (and MoneroHash misses a lot of nodes). Now I've filled that gap :)

<jkirsch10:matrix.org> What happened in June there? The big drop then coming back higher than before the drop... change in scanning?

<rucknium> I use a dedicated scanner written in rust (mostly by @boog900:monero.social ) that takes less than 24 hours to crawl the network. I mean, get all reachable peers.

<rucknium> @jkirsch10:matrix.org: I think it's a spy network going offline, then coming back.

<rucknium> But they don't have the very identifiable spy node fingerprint. So they aren't labeled as such.

<jkirsch10:matrix.org> Curious what is your criteria for determining that all reachable peers have been found, that is something that is assumed in my paper, not formally defined. I guess any definition would assume a convergence criteria, idk

<rucknium> Get peer list from each node and exhaust them.

<rucknium> I mean, start with the seed nodes and branch out, gathering peer lists as I go.

<rucknium> You were doing it more "manually", with actual monerod nodes connecting and disconnecting.

<rucknium> And note that the webapp counts each IP address only once. There are some nodes on the same IP address, but different ports.

<jkirsch10:matrix.org> Yes right exactly. Ok Cool. Your approach is much more sophisticated then mine. Perhaps as inspiration from the paper you will look at the edge characteristics between and among the suspected spy nodes and the rest of the nodes. My findings were pretty much that 24% of nodes were suspected spy nodes, they accounted for 67% of [... too long, see mrelay.p2pool.observer/e/5Ovbxq0LRE9oczVi ]

<jkirsch10:matrix.org> Meaning the spies were highly effective in embedding themselves in white lists of all other nodes

<rucknium> > Here when I say "connected" or "edge" i dont mean active open connection, i just mean on other nodes' white list so there is at least the potential for connection

<rucknium> That's mostly where I differed with you in interpretation. It sounds like you paper says that the edge were current active connections, but the peer list includes a random subset of the 1000-peer white list, not the actual current connections.

<rucknium> Yes. The spy nodes only emitted the IP addresses of other spy nodes when it shared their peer lists. A "normal node" would have a (roughly uniform) random set of all reachable nodes on the network.

<jkirsch10:matrix.org> right exactly, the intention there is to refer to white list not active connections. I do beleive I call that out in the paper, what the intention is, but regardless the language is confusing and unless you read that caveat... even more confusing

<rucknium> @jkirsch10:matrix.org: We need to get to the rest of the meeting agenda, but I encourage you to stay for the last agenda item if you want, Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (arxiv.org/pdf/2609.10260)

<rucknium> Thank you for coming!

<jkirsch10:matrix.org> Great. Thank you for inviting me today. My personal opinion is the paper has many shortcomings. I hope it is somewhat useful to you - perhaps primarily for spurring ideas on what types of experiments to do or what to investigate next.

<jeffro256> Thank you, jkirsch10

<rucknium> 4. 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/393zxq0LUXhqMDNR ]

19:23 <+br-m> <jeffro256> I wonder if LinkingLion was active in 2022... <-- they have been active since like 2018. Here a PR from 2020 that was related to LinkingLion: monero-project/monero #7073

<jeffro256> Sorry I haven't updated that chart in a few weeks

<jeffro256> Interesting, selsta ...

<jberman> On Research items: helioselene audit is nearing release, and we settled on a candidate in last week's meeting for the audit of circuit + gadgets (second round of review) and fcmp-plus-plus lib

<jeffro256> I assume @tobtoht isn't here?

<sgp_> Luke made a patch to address one finding from the LA Helios/Selene review (which my understanding is more of a "best practice" recommendation than a direct risk as implemented). That final report is expected in the coming days: monero-oxide/monero-oxide 77788c3

<jpk68:matrix.org> Potentially a dumb question, but is the identity of the firm authoring the Helioselene audit publicly known yet?

<sgp_> Least Authority

Oh, that's the name of a company, not some security policy / system / approach / whatever

<jberman> On integration, we knocked off a whole list of items that have been on the to-do list: hot-cold integration, guarantee every curve tree root is unique ( seraphis-migration/monero #462 ), we merged RandomX V2 into our staging branch and those changes LGTM though there is still the more minor question of d [... too long, see mrelay.p2pool.observer/e/qsWNx60LNnJ0V2Jy ]

<sgp_> rbrunner: correct

<sgp_> @jberman: yay preparing for worst case scenarios

<jberman> On upstream FCMP++ integration PR's: first 2/3 PR's from the Audit Phase 2 are merged, latest outstanding open PR is the curve tree building code which is a significant PR: monero-project/monero #10724

<jberman> I plan to prepare a request for quotes for Audit Phase 2 within the next day or 2, so @sgp_:monero.social can start contacting firms there and we can get that rolling

<jberman> Again, I don't think upstream PR's need to be blocked by pending audits

<sgp_> @jberman:monero.social: would it potentially make sense to get quotes for 2+3 together, or is that not feasible?

<jberman> It might

<jberman> I'll work on preparing Phase 3 PR's next in that case to get a better a read

<sgp_> Sounds good

<jberman> This Phase 2 isn't too big

<rucknium> Anything more on this item?

<jberman> nothing from me

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

<jberman> We can schedule beta v3 launch during this meeting. The code is now ready to go. Can see all the items we knocked out in that checklist there

<jberman> I think it would be nice to have some testing done on current testnet before the fork as well, but caution that we don't want people stress testing current testnet

<jberman> Another test that would be good to have people check is migrating a testnet wallet from current testnet to a fork compatible wallet (i.e. create and use a wallet now on current testnet, and then open that wallet with the new beta v3 software)

<jberman> So with that in mind, how about we target Monday Oct 5th for the fork to give people some time to get set up again with current testnet and with the new beta v3 software before the fork. We should be able to get binaries released within the next day

<jeffro256> We also wanted to discuss the initial penalty free zone parameter. Is 10MB okay? Would allow for 20MB blocks at HF if full penalty is paid. A 10MB param would help us skip the initial "warm-up" phase and get back to spamming at volumes similar to when we left off

<rucknium> Oct 5th sounds good to me

If RandomX v2 is merged into the stage branch, then version 3 will have it too, right?

<jeffro256> Yes

P2Pool's v5 branch (FCMP++/Carrot/RandomX v2 compatible) is ready for testing then

Oct 5th sounds good

<rucknium> @jeffro256: @jeffro256:monero.social: Have all the bugs have been fixed with that? (the hard way?)

I'll have P2Pool v5.0-beta release before that

<jeffro256> sech1: Does that branch have this change in it?: seraphis-migration/monero #456.

<jeffro256> Or at least uses the carrot_core code that is up-to-date with fcmp++-stage?

<jeffro256> If using an up-to-date carrot_core, then nothing else needs to be done

No, it doesn't

I'll go through all the changes and update P2Pool side

It doesn't use carrot_core code. All math is tailor-made for P2Pool

<jeffro256> IIRC that's the only backwards-incompatible change to Carrot since beta v2

yeah, if it was merged 15 hours ago, P2Pool definitely doesn't have it yet

<jeffro256> Changes are posted to the spec repo, the tweak is very simple on the sender side

<jeffro256> Does p2pool implement scanning code?

No

It does "scanning" by reconstructing the sender side for each output. But it's only used to display "this wallet got this much XMR in this block" message

<jeffro256> Ok sweet, then hopefully it shouldn't be too hard. In the d_e derivation, simply include K^j_v right after K^j_s

sounds simple enough

<jeffro256> There was also the T generator change: monero-project/monero #10963, so make sure that that value matches upstream

<jeffro256> The T value was also updated in the spec

<jeffro256> I'm sure you know, but there's always the carrot_convergence tests to verify impls against: github.com/seraphis-migration/moner…s/unit_tests/carrot_convergence.cpp

<rucknium> Anything more on stressnet prep?

<rucknium> 6. Bulletproofs+ Aggregate Range Proof Issue Identified and Resolved (magicgrants.org/2026/09/22/Bulletproofs+-Report).

<jeffro256> @rucknium: It should be the same bugs that we fixed increaseing it to 625

<jeffro256> 625K

<sgp_> I don't have much to add on this section, besides "read the post and the review"

<sgp_> The original work that Dr. Wang was hired for, on more efficient range proofs, is still coming later this year

<sgp_> If time permits, I hope to do a Plaintext podcast on this topic

<ack-j:matrix.org> Needless to say, magic has been very happy with the work of Dr Wang and his colleagues

jeffor256 yes, I know about generator T, and I did integrate the convergence tests

<rucknium> Is this summary correct?: BP+ paper was written. Through CCS, a team was hired to review it. They found a problem with the original proof, but deemed the actual theorem to be correct. However, that team didn't write a rigorous-enough proof of the final result. Then Dr. Wang looked at it and noticed the lacking rigor. They wrote a rigorous proof that fully repaired the original BP+ proof.

<rucknium> BP+ was a very modest reduction to the proof size IIRC. Makes one wonder about the risk-reward balance on that one.

<sgp_> That is largely correct. It's not that they wrote a bad proof for the initial review, it's that they said it looked good without demonstrating so

<sgp_> "here's an issue, but it is fine in practice", basically

<sgp_> which, technically, was true, but not supported at the time

<rucknium> Thanks for organizing the most recent review, MAGIC

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

<rucknium> Anything on this item for now?

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

<rucknium> @gingeropolous:monero.social and I have been working on reproducing the attack in monerosim. It looks like the attack is reproducible. I have been testing countermeasures.

<vtnerd> doesn’t this require lots of /24 addresses, or am I missing something … ?

<rucknium> @vtnerd:monero.social: Yes it does. Well, about 1,000 IP addresses, each in its own /24

<rucknium> I think it's possible to make this attack less costly, for little cost to monerod

That's not nothing ...

<rucknium> I mean, make the attack more costly

<vtnerd> yes, understood.

Nice that it's possible now to actually test it, no?

<rucknium> I am pretty sure that the attack would be detectable through a network scan of mainnet. I looked through a couple of recent network scans and I didn't see any evidence of the attack being attempted. I mean the Nyx attack of eclipsing an established unreachable node. The Moros attack is different, which I will get to later.

<rucknium> rbrunner: Yes. Our ability to test this was the result of several past decisions made in years past.

<rucknium> Mainly, @gingeropolous:monero.social adapting Shadow for Monero, creating monerosim. And the hardware purchases of 1TB RAM. Thank you, CCS donors!

<jpk68:matrix.org> @rucknium: Do you think it would be eventually worthwhile to have a written document outlining the specific required logic for handling peers and such, in order to protect against faulty implementations and ensure reference implementation behaviour remains correct?

<rucknium> @jpk68:matrix.org: Definitely.

<rucknium> A lot of the logic was inherited from Monero's ancient Cryptonote ancestors. The ancestors speak no longer (or at least they don't identify themselves).

<ack-j:matrix.org> It would be interesting to scan the git history of monerod to see which lines of code are the oldest without being updated

<rucknium> We don't know the reason things are written they way they are. Maybe it was to maximize connectivity with honest nodes but they did not fully explore what an adversary could do.

<jpk68:matrix.org> I mean, even with some remaining similarities, this research could probably be useful for projects like Zano and MobileCoin (if it still exists...) as well

<rucknium> @ack-j:matrix.org: One of the big ones is white list size 1,000, which is with the oldest commit of the original codebase.

<rucknium> The reason that I think the attack is detectable on mainnet is that the attacker needs to stuff reachable node white lists with their own IP addresses, pushing out honest IP addresses. In that case, the peerlists the honest nodes share would be biased. I performed some chi-squared tests and found no obvious bias.

<rucknium> I think it's time to stop using the "Chesterton's Fence" reasoning to give the benefit of the doubt to the original cryptonote network code.

<rucknium> rbrunner and I puzzled over some of that code when we added the /24 deduplication rule.

<jpk68:matrix.org> @rucknium: As in, stop questioning it, or begin questioning it? I assume you mean the latter

<rucknium> Begin questioning it.

<rucknium> The second attack in the paper, Moros, requires the attacker to stuff the peerlists of seed nodes to eclipse brand new nodes.

Well, not knowing why a fence is there is compatible with seeing that today it's not good anymore

<rucknium> The research team actually did that to mainnet seed nodes.

<ack-j:matrix.org> mrelay.p2pool.observer/m/matrix.org/WELbdikXXqsfwVJzOAndWHkQ.jpeg (ima_acacd9b.jpeg)

<ack-j:matrix.org> @ack-j:matrix.org: Results from git blame

<ack-j:matrix.org> Over every line in the monero repo

<rucknium> They said they did it in the paper. And I think I see some evidence of their poisoning in late November to mid December 2025, in the network scan data.

Hmm. Is that still friendly, to be expected from people who write papers?

<rucknium> Which was coincidentally around the time that I though my network scanner code was failing to do its job. It would make sense that my scanner was finding it hard to scan if the seed nodes were poisoned.

<rucknium> rbrunner: IMHO, they should not have done that

<rucknium> They could have set up their own "seed nodes", even on mainnet, and modified their nodes' code to point to those seed nodes. You could have the same effect IMHO. I mean, test the theory without messing with mainnet real seed nodes.

<rucknium> They say in the appendix that actual new Monero nodes would have eventually gotten out of the eclipse.

Did not fully read the paper. Is that "Moros" attack alone able to achieve something dangerous?

<rucknium> Tor has a research safety board for this kind of thing by the way: research.torproject.org/safetyboard

<rucknium> rbrunner: It could eclipse newborn nodes from the start. Not as widespread of a problem as eclipsing all the established unreachable nodes.

I see

<rucknium> The countermeasures I am testing are 1) Expand the whitelist size from 1,000 to 10,000. 2) Try to add a new conenction from the white list first instead of the gray list. 3) Select new connections uniformly from the white list instead of biasing toward the most recently seen ones.

<rucknium> Those countermeasures are the intersection of what I think may be effective and what I can actually code myself in C++

<rucknium> :D

Sounds interesting, where it's probably not immediately clear for all 3 whether it's a good idea or makes things actually worse

<rucknium> I am pretty sure #1 cannot make things worse, at least with this specific attack.

Is the gray list still good for something with 2) implemented?

<ofrnxmr> can the white list even get that big without constantly evictinf and switching peers?

<rucknium> Actually this research group has suggested to Monero twice to increase the white list size limit.

<rucknium> rbrunner: Yes because there is a housekeeping method that tests gray list peers for reachability, then puts them in the white list if they are reachable. But it doesn't add those as an actual connection unless it is later selected from the white list as a new connection.

<rucknium> The purpose of increasing the white list size is to prevent manipulative adversaries from pushing out honest peers from that list. If the list is larger than the total reachable IP addresses, the honest peers cannot be pushed out.

<vtnerd> one problem I see is that if you restart monerod, then the recently connected helps with dead ip/port pairs

<rucknium> This is the paper last year where they suggested increasing the white list size: moneroresearch.info/248 Shi, R., Peng, Z., Lan, L., Ge, Y., Liu, P., & Wang, Q., et al. 2025, February 24–28, Eclipse Attacks on Monero’s Peer-to-Peer Network. Unpublished paper presented at Network and Distributed System Security (NDSS) Symposium 2025.

<vtnerd> *selecting/bias from the recently connected

<rucknium> @vtnerd:monero.social: IIRC, on a restart you select from the anchorlist first.

<rucknium> I am not committed to uniform selection from the white list. Just testing things now.

<rucknium> More on this agenda item for now?

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

<ofrnxmr> Thanx

<gingeropolous> thanks!