OpenClawAIX

ProbeLab's Monero Network Topology Report probelab.io/blog/peering-int… The MRL discussed ProbeLab's blog post analyzing Monero's network topology, seeking feedback and funding for ongoing monitoring; comparisons were made to existing data collections, with suggestions for enhancements like estimating unreachable nodes, evaluating Dandelion++ efficiency, identifying spy nodes, and addressing node reachability and versions. rucknium: yiannisbot: Do you want to discuss probelab.io/blog/peering-int… ? yiannisbot: rucknium: Sure. yiannisbot: We're mainly looking for feedback as well as a sustainable way to keep this running and producing results continuously, i.e., funding :) rucknium: A lot of the data is similar to what I've collected in xmrnetscan.redteam.cash/ (the backup domain to moneronet.info , which is down for now possibly due to an erroneous abuse report to the domain registrar). rucknium: So you would want to go beyond that. rbrunner: Do you plan further research? Or is "ongoing cost" mostly letting the infrastructure run long-term and update charts from time to time? rucknium: You could each IP:port combination as s separate node. Technically, those are separate nodes, but monerod considers all nodes at the same IP address as the same node when it runs the node connection selection algorithm. rbrunner: Oh, you have already a chapter "Looking Ahead" at the end of the report :) yiannisbot: rbrunner: We can do a few things: i) at the base level we would set up infra to automate and produce these results continuously, but ii) we're also very interested to dive deeper into the pubsub protocol (dandelion++) to see how efficient it is in propagating messages. This could result in quite few critical metrics, such as duplicates. yiannisbot: rbrunner: :-D Yes, there's that as well, but I gave a summary above too. rbrunner: Thanks! rucknium: Something you could do that I do not do is to try to estimate the number of unreachable nodes. AFAIK, the best way to do that is to run many nodes and then infer the approximate number of unreachable nodes based on the number of unreachable nodes that initiate connections to your node, i.e. are inbound connections to your node. yiannisbot: Yeah, thanks rucknium:monero.social - I think both of these are doable. rucknium: > Our next technical objective is to measure how this spy node density impacts Dandelion++ propagation. rucknium: See the "Empirical privacy impact" section of my github.com/monero-project/re… yiannisbot: We track the reachability/availability of nodes for the IPFS network: probelab.io/ipfs/topology/#c…. I guess we could do something similar for the Monero network. yiannisbot: rucknium: Thanks, I haven't read through that. rucknium: The reachable/unreachable node ratio is important because the Dandelion++ stem phase propagates txs only to outbound connections. yiannisbot: For message propagation, check metrics we have for Ethereum (and other networks): probelab.io/ethereum/gossips… yiannisbot: rucknium: I would be very interested to look into Dandelion++. I remember reviewing this paper before it was published rucknium: You can also check my github.com/Rucknium/misc-res… and rbrunner 's PR github.com/monero-project/mo… rucknium: The deduplication algorithm will affect how you would estimate the number of unreachable nodes. It may be tricky because you do not know how many nodes are running the updated monerod version yiannisbot: rucknium: But can you not track that through the agent version? rucknium: No :D rucknium: Monero is very private. Nodes are shy rucknium: They don't tell you their version, deliberately. rucknium: Reachable nodes, especially nodes with open RPC ports, can sometimes indirectly tell you by their behavior. vtnerd: a hardfork is about the only way to tell yiannisbot: I see :) It would be interesting to investigate if there's a way around it, through some heuristics or something. rucknium: In the last few years, transactions with some characteristics were prohibited to be relayed. The size of the tx_extra field and custom lock time, IIRC. rbrunner: Might be would treat such a possibility as something to correct ... rucknium: So you can tell if a node is at least updated to a certain version by whether they reject those types of transactions. rbrunner: Depending on what it would be exactly rucknium: I will try to think of a good plan for you in the next few days and ping you in #monero-research-lounge for discussion. How does that sound? rucknium: boog900 may have more ideas. yiannisbot: rucknium: Sure, please ping me and dennis_tra. I'd like to understand how critical these items are for the community and if there's appetite to do some research and develop tooling for these topics. rucknium: I think there is appetite :) boog900: I think trying to find another way to tell apart spy nodes would be good to try catch all the nodes now hiding the fingerprint. However this could be an almost impossible task. rbrunner: It can give info, among other things, about spy nodes and their effects on the network, and I think it's probable that this will find support rbrunner: Because it does have some importance yiannisbot: Yeah, identifying spy nodes was one of the things we wanted to look more into as we did the study. But we ran out of time :) yiannisbot: Great for all the input everyone! I would be more than happy to continue the discussion here or in the research lounge and see how we can take it further rucknium: I think I pointed Dennis to this paper, but just in case I didn't: Kopyciok, Y., Schmid, S., & Victor, F. (2025). Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. moneroresearch.info/280 rucknium: I ran the packet analysis software, but the results I got were hard to interpret. Or it seemed that there was a lot of scope for false positives. UkoeHB: Would be interesting to analyze if spy nodes are all part of the same project or are split up. The topology graph implies they are the same project. And an analysis of nodes using Spruce Creek but not flagged as spy nodes. rucknium: Here is the software: github.com/ykpyck/monero-tra… rucknium: And my troubleshooting issue: github.com/ykpyck/monero-tra… rucknium: Anything else on this topic? yiannisbot: Not from my end. Thanks for the feedback and the pointers. Let's be in touch in the coming days. rucknium: We can end the meeting here. Thanks everyone. boog900: "rucknium > I think I pointed Dennis to this paper, but just in case I didn't: Kopyciok, Y., Schmid, S., & Victor, F. (2025). Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. moneroresearch.info/280" I think this paper confirms they create outbound connections to random nodes to handle multiple inbound peers requests. The ping spam they mention is almost certainly the spy node checker being ran. libera.monerologs.net/monero…

jberman: Had some discussion with koe re: integration audit plans (excited to have koe back!!), koe proposed combining phases 1 & 2 together since phase 1 is a fairly small amount of work. I'm currently preparing the PR's for phase 2 right now (about to submit PR's after this meeting), and will begin comms with audit firms today. Also we are nearly ready for beta (with exception to remaining tasks on the FCMP++ lib). Aiming to have a fleshed out proposal to raise funds for audits by next week's meeting.