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

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

<rucknium> 1. Greetings

<vtnerd> Hi

Hello

Hi

<jberman> waves

<jeffro256> Howdy

<gingeropolous> howdy do

<yiannisbot:matrix.org> Hi

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

<gingeropolous> ironing out kinds in monerosim with @rucknium:monero.social 's help

<iamnew117:matrix.org> hello

<yiannisbot:matrix.org> Apologies I didn't add it to the issue. We've been working on the Monero Network Topology, which my colleague @dennis_tra:matrix.org has posted here before: probelab.io/blog/peering-into-priva…ve-into-the-monero-network-topology.

<rucknium> me: Started analysis of the output of @gingeropolous:monero.social 's github.com/Fountain5405/monerosim. So far it is mostly as expected, i.e. not very different from the characteristics of mainnet log data.

<rucknium> @yiannisbot:matrix.org: Thanks. Do you want to discuss it at the end of the meeting?

<vtnerd> Me: mostly completed zmq tx pub issues, but still one remains. Also got websocket /feed working between lws and lwsf, such that instant updates and reduced API chatter is now possible

<yiannisbot:matrix.org> We wanted to get feedback on the study and discuss how we could improve our setup, i.e., what extra metrics would be of interest, as well as, whether there's interest to run our scripts continuously and present results at: probelab.io

<yiannisbot:matrix.org> @rucknium: Sure. What time is the end, roughly?

Rereading papers. Planning to review carrot stuff, coordinate discussion for wallet design around carrot, figure out multisig for fcmp++

<rucknium> @yiannisbot:matrix.org: Probably at about 17:30 or 17:40 UTC.

<jberman> Me: 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. A [... too long, see mrelay.p2pool.observer/e/gsb8uu4KZExDcjlw ]

<rucknium> Welcome back, UkoeHB :)

<rucknium> 3. FCMP code integration audit overview (seraphis-migration/monero #294).

:)

<jberman> Basically shared my update on it above

<rucknium> Anything else on this agenda item?

<jberman> Aiming to have a fleshed out proposal to raise funds for audits by next week's meeting

<rucknium> 4. FCMP beta stressnet.

<rucknium> AFAIK, beta stressnet will use tx relay v2 by default. monerosim's 1000-node run switched to tx relay v2 midway through. Things seemed to work properly in the simulation.

<jberman> Scaling is done and in the branch (thank you @jeffro256:monero.social, ArticMine , @boog900:monero.social and everyone involved in landing on a solution), beta stressnet branch is created. We have some final simple checklist items to cross off on our end from here seraphis-migration/monero #166 , and [... too long, see mrelay.p2pool.observer/e/9b2eu-4KUGNoVkY1 ]

<jberman> Correct beta stressnet will use tx relay v2 by default

<jberman> It's in the branch already as well

<rucknium> Anything else on beta stressnet?

<rucknium> @yiannisbot:matrix.org: Do you want to discuss probelab.io/blog/peering-into-priva…ve-into-the-monero-network-topology ?

<yiannisbot:matrix.org> @rucknium: Sure.

<yiannisbot:matrix.org> 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.

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.

Oh, you have already a chapter "Looking Ahead" at the end of the report :)

<yiannisbot:matrix.org> 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:matrix.org> rbrunner: :-D Yes, there's that as well, but I gave a summary above too.

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:matrix.org> 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 monero-project/research-lab #126#issuecomment-2460261864

<yiannisbot:matrix.org> We track the reachability/availability of nodes for the IPFS network: probelab.io/ipfs/topology/#chart-availability-classified-ts. I guess we could do something similar for the Monero network.

<yiannisbot:matrix.org> @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:matrix.org> For message propagation, check metrics we have for Ethereum (and other networks): probelab.io/ethereum/gossipsub

<yiannisbot:matrix.org> @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-research/b…onero-peer-subnet-deduplication.pdf and rbrunner 's PR monero-project/monero #9939

<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:matrix.org> @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:matrix.org> 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.

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.

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:monero.social for discussion. How does that sound?

<rucknium> @boog900:monero.social may have more ideas.

<yiannisbot:matrix.org> @rucknium: Sure, please ping me and @dennis_tra:matrix.org . 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.

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

Because it does have some importance

<yiannisbot:matrix.org> 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:matrix.org> 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.

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-traffic-analysis

<rucknium> And my troubleshooting issue: ykpyck/monero-traffic-analysis #1

<rucknium> Anything else on this topic?

<yiannisbot:matrix.org> 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.

Thanks :)

<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

<boog900> 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.

I don't mean to drag out the meeting, but I'd like to bring up a recent CCS proposal I've opened, if that's fine

<rucknium> jpk68: Yes, you can bring it up.

It has to do with improving I2P support in monerod - StormyCloud, a nonprofit which works with the I2P project, has agreed to fund the proposal in full

-- with some changes to the milestones and funding structure

I'm just waiting to hear back from plowsof about some changes to it.

<rucknium> This proposal? repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/650

Yes.

I thought I would mention this in case anyone was interested/wondering; the research portion of it also has to do with spy nodes to some extent

Not really in a direct sense, however I recently saw an issue opened by Gingeropolous (I think) about encouraging the use of anonymity networks to mitigate spy nodes. One of the major pain points with this, in my opinion is the fact that you can't fully sync a node over Tor or I2P

<rucknium> @vtnerd:monero.social: Do you have thoughts on this? ^

Perhaps if people are willing, the question of allowing node sync over I2P could be reopened - I think I2P (especially with SAM support) alleviates a lot of the bandwidth issues that were causing concerns

<rucknium> Syncing everything over I2P also presents a sybil attack concern.

<boog900> It was the cheapness of generating addresses more than bandwidth that was the concern.

Yes, true. There is definitely more to discuss/consider in that regard

Aside from that specific issue though, I believe it would solve quite a few UX problems with anonymity networks :)

And even if you can't sync a node over I2P, spy nodes would perhaps be less of a problem, since you could more easily connect to a public I2P node if support is included in the GUI

<vtnerd> we’ve kept off syncing over i2p/tor because it destroys the limited bandwidth + has eclipse attack issues (ipv4 is naturally a deterrent)

<vtnerd> I thought I2P support was in the GUI? I don’t look at that (the gui) as often as I should

Nope :)

Well, you can configure SOCKS proxies in the GUI, I believe

<vtnerd> I never saw an advantage to the SAM protocol because you still have to know/setup the port for the SAM protocol

<vtnerd> yes, so there is support for it just indirectly

Do you mean from a UX standpoint?

<vtnerd> yes theres still just as much friction, unless you just auto-assume the port

As mentioned in the link below, there is a lot of metadata leakage that can occur with I2P using SOCKS

<vtnerd> I guess its easier than manually setting up your hidden service address

I2P devs are strongly in favor of deprecating the I2P SOCKS route and using SAM instead

<vtnerd> that disclaimer is for generic usage, not our specific case

vtnerd: Yes, that too. You won't need to manually configure tunnels

I agree with that, however there are many other reasons, as listed here:

<vtnerd> as in, our p2p protocol can still leak metadata even with sam, its not specifically a socks issue

From the standpoint of I2P nodes, yes

<vtnerd> the only benefit is the auto-creation of services, but with the caveat your still typically setting up i2p + knowing the port

Users using I2P as an anonymizing layer also are negatively affected by support for only SOCKS, because addresses can be leaked/correlated with other services

<vtnerd> are you putting SAM in gui or monerod? how are you going to: “Provide GUI indication of external router status up/down” in the gui?

<vtnerd> because addresses can be leaked/correlated with other services -> you mean if they reuse an endpoint?

Yes. All applications which use the same SOCKS proxy (as an I2P bridge) share the same destination address

<vtnerd> fwiw Im partially against syncing over I2P as its probably usually a bad idea, but more favorable to supporting SAM

<vtnerd> same destination address? you mean in the reverse direction?

<vtnerd> that sounds like a sh** implementation in I2P to me, but I dunno

<vtnerd> tor just creates tunnels on the fly iirc

vtnerd: At present, the plan is to replace the I2P SOCKS code path with SAM, as well as to add a page in the GUI for configuring router connections. Plus a rewrite of docs, and migration options for current i2p-zero users

vtnerd: That's what SAM does, it allows the application to create specific tunnels

If you look at the link I sent above, there is more information about I2P SOCKS issues under the "What's wrong with SOCKS?" header

<vtnerd> yes, but there’s zero reason this couldn’t be done over SOCKS, unless Im missing something. its not like every SOCKS connections uses the same ip+port coming in

<vtnerd> yes, they’re primarily complaining about routing arbitrary stuff over SOCKS as its typically a bad idea. But monerod+socks+i2p has already been investigating for scrubbing, so its a non-argument

I'm restating what has already been said in the original CCS the I2P devs opened a few years ago. You may find the information there informative

<vtnerd> and there’s nothing about re-using i2p destination addresses

Thanks for sharing your perspective though, I appreciate it

Again, they share the return address

<vtnerd> then why don’t they say that in this writeup? They wasted a bunch of words to say that generic protocols over i2p is bad.

I'm not sure to be honest. I must admit though, after looking into this I am pretty convinced that SAM would be a huge improvement. Bitcoin Core has already done this and it works really well.

<vtnerd> I really doubt they re-use connections, or need to for their implementation, but I could be missing something

<vtnerd> yes, if it reduces friction for starting inbound services its probably a win

You also have to trust users to set up the SOCKS tunnel correctly, which is done differently for every I2P implementation. Whereas SAM is a standardized protocol that does everything for you, including managing keys

Yes :)

It is also worth noting that the CCS will be changed to a commit/feature-based milestone structure rather than a time-based one

That is in the works, I am just waiting to hear back from some people

<vtnerd> setup the socks correctly? its the same level of difficulty of setting up i2p+sam port

<vtnerd> thats been my complaint - you can basically get everything but inbound working with same level of friction

No, because users will have to use a different SOCKS tunnel for every application to avoid correlation

<vtnerd> ….again …. why? each socks tunnel can be a unique i2p tunnel.

<vtnerd> and they never mention this in the writeups, this should be highlighted on that page

Because it's a pain and fixing it would improve UX

I'm not sure what you mean by 'not mentioned in the writeups'

<vtnerd> as in each SOCK connection is a unique i2p connection

<vtnerd> the fact that app A and app B use the same socks port is irrelevant as each connection will be unique anyway

I'm not quite sure, to be honest.

Regarding your last message, again, they share the same destination address

This is still a heuristic

<vtnerd> an example, tor would have massive correlation issues with its exit nodes if SOCKS were inherently this bad

Yes, and this is why I2P devs have never recommended SOCKS for applications like this. You can put any protocol over I2P, pretty much

<vtnerd> I guess I should explain - with SOCKS you only get to make one proxied request. You can’t re-use the connection

That doesn't mean it's going to be good or work well

<vtnerd> so you can’t footgun yourself with SOCKs, except for the issue with privacy within the proxied data

<vtnerd> otherwise tor+socks would’ve been a disaster long ago with its exit nodes

<vtnerd> its literally the same thing for outbound connections, thats my only point, and if you think you can make it easier for setup have at it

Thank you :)

<vtnerd> Im just not convinced that people can setup i2p but not the hidden service element. there’s already tons of friction

Of course there is still much to discuss and I am very open to taking input from people about this. Nothing is set in stone, and I'm just saying I think it's worth looking into

<jpk68:matrix.org> Not sure why my IRC connection dropped. I'm still here if there are any other questions/concerns :)

<vtnerd> jpk68_looks like i2p uses the same source address for socks, per run, instead of cycling through them like tor.

<vtnerd> if you can hook into SAM to create a new circuit/tunnel per tx-relayed that would definitely be a win

<vtnerd> we may have to randomize when this occurs though, as that too could leak metadata about when a tx is relayed

<vtnerd> but I forgot this is an outstanding issue with tor that someone pointed out (although typically with tor we are cycling through connections anyway, which is probably better than manually requesting one)

<vtnerd> although with fcmp++ I guess it doesnt really matter anymore

<jpk68:matrix.org> Yes, for sure :)

<jpk68:matrix.org> That is one of the main research areas in the proposal

<vtnerd> er nevermind (most) of this, creating new tunnels per tx relay is likely problematic. anyway we randomize which tor/i2p connections a tx gets relayed over anyway, to mitigate this issue

<vtnerd> can you be more specific?

<vtnerd> with tor we likely need randomized destructions of connections. that way we slowly cycle through circuits+rarely re-use same connection to relay tx.

<vtnerd> with i2p it looks trickier, because socks never cycles through routes, but then we are left to do this “on our own” which is unfortunate compared to tor

<vtnerd> @jpk68:matrix.org: the ccs proposal doesn’t mention anything about what I’ve just said?

<jpk68:matrix.org> @vtnerd: Have you checked the updated version?

<jpk68:matrix.org> "Decide on ACCEPT vs FORWARD for incoming connections, permanent vs transient destinations"

<jpk68:matrix.org> That's the same thing, no?

<jpk68:matrix.org> Whether or not new tunnels/identities are created per transaction, etc.

<vtnerd> I dont see how that relates. incoming here refers to the people accepting the txes to be relayed (and so to does destination); transient circuits/tunnels outgoing is more useful in our context

<jpk68:matrix.org> That could be part of it as well

<vtnerd> transient destinations just makes the connections less stable (as the p2p sharing is constantly “old”), whereas transient outgoing provides protection against sending 2 txes to the same peer

<vtnerd> *transient outgoing -> transient connections/circuits/tunnels, etc

<vtnerd> as in, if you want inbound addresses to constantly change, you’ll have thoroughly test that it doesn’t destroy the ability to make new p2p connections in sane way. imagine if every ipv4+port inbound p2p just randomly changed its ip every hour, the peerlist sharing will be terrible

<vtnerd> in fact, this is a point against SAM, in practice we want long-lived inbounds to keep the p2p system health

<vtnerd> I’ll just start a discussion on ccs site.

<jpk68:matrix.org> It does seem like a bad idea to have transient destinations for I2P nodes (P2P traffic), but is that even something we have to worry about if I2P nodes can't sync the chain right now?

<vtnerd> yes, it should make it harder for nodes to relay to such peers

<vtnerd> As an exaggerated example, if the destination cycled every minute, the majority of the connections are likely to nodes using the “existing” long-term destination setup. we would have tons of peers making useless entry points, and slow down p2p connection making

thanks vtnerd