15:00:53
rucknium:
MRL meeting in this room in two hours.
17:00:09
rucknium:
Meeting time! https://github.com/monero-project/meta/issues/1352
17:00:16
rucknium:
1. Greetings
17:00:40
vtnerd:
Hi
17:00:42
rbrunner:
Hello
17:00:46
UkoeHB:
Hi
17:01:03
jberman:
waves
17:01:17
jeffro256:
Howdy
17:02:10
gingeropolous:
howdy do
17:02:15
yiannisbot:matrix.org:
Hi
17:02:42
rucknium:
2. Updates. What is everyone working on?
17:03:26
gingeropolous:
ironing out kinds in monerosim with @rucknium:monero.social 's help
17:03:43
iamnew117:matrix.org:
hello
17:04:27
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: https://probelab.io/blog/peering-into-privacy-a-deep-dive-into-the-monero-network-topology/.
17:04:28
rucknium:
me: Started analysis of the output of @gingeropolous:monero.social 's https://github.com/Fountain5405/monerosim. So far it is mostly as expected, i.e. not very different from the characteristics of mainnet log data.
17:04:58
rucknium:
@yiannisbot:matrix.org: Thanks. Do you want to discuss it at the end of the meeting?
17:05:15
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
17:05:28
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: https://probelab.io
17:05:35
yiannisbot:matrix.org:
@rucknium: Sure. What time is the end, roughly?
17:05:57
UkoeHB:
Rereading papers. Planning to review carrot stuff, coordinate discussion for wallet design around carrot, figure out multisig for fcmp++
17:06:52
rucknium:
@yiannisbot:matrix.org: Probably at about 17:30 or 17:40 UTC.
17:09:00
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 https://mrelay.p2pool.observer/e/gsb8uu4KZExDcjlw ]
17:09:57
rucknium:
Welcome back, UkoeHB :)
17:10:04
rucknium:
3. FCMP code integration audit overview (https://github.com/seraphis-migration/monero/issues/294).
17:10:16
UkoeHB:
:)
17:11:47
jberman:
Basically shared my update on it above
17:13:58
rucknium:
Anything else on this agenda item?
17:14:45
jberman:
Aiming to have a fleshed out proposal to raise funds for audits by next week's meeting
17:15:46
rucknium:
4. FCMP beta stressnet.
17:17:39
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.
17:18:16
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 https://github.com/seraphis-migration/monero/issues/166 , and [... too long, see https://mrelay.p2pool.observer/e/9b2eu-4KUGNoVkY1 ]
17:19:10
jberman:
Correct beta stressnet will use tx relay v2 by default
17:19:33
jberman:
It's in the branch already as well
17:21:37
rucknium:
Anything else on beta stressnet?
17:23:22
rucknium:
@yiannisbot:matrix.org: Do you want to discuss https://probelab.io/blog/peering-into-privacy-a-deep-dive-into-the-monero-network-topology/ ?
17:23:47
yiannisbot:matrix.org:
@rucknium: Sure.
17:24:11
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 :)
17:27:47
rucknium:
A lot of the data is similar to what I've collected in https://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).
17:27:58
rucknium:
So you would want to go beyond that.
17:28:30
rbrunner:
Do you plan further research? Or is "ongoing cost" mostly letting the infrastructure run long-term and update charts from time to time?
17:29:19
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.
17:30:29
rbrunner:
Oh, you have already a chapter "Looking Ahead" at the end of the report :)
17:30:56
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.
17:31:17
yiannisbot:matrix.org:
rbrunner: :-D Yes, there's that as well, but I gave a summary above too.
17:31:31
rbrunner:
Thanks!
17:31:44
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.
17:33:15
yiannisbot:matrix.org:
Yeah, thanks @rucknium:monero.social - I think both of these are doable.
17:34:42
rucknium:
> Our next technical objective is to measure how this spy node density impacts Dandelion++ propagation.
17:34:42
rucknium:
See the "Empirical privacy impact" section of my https://github.com/monero-project/research-lab/issues/126#issuecomment-2460261864
17:34:44
yiannisbot:matrix.org:
We track the reachability/availability of nodes for the IPFS network: https://probelab.io/ipfs/topology/#chart-availability-classified-ts. I guess we could do something similar for the Monero network.
17:35:40
yiannisbot:matrix.org:
@rucknium: Thanks, I haven't read through that.
17:35:56
rucknium:
The reachable/unreachable node ratio is important because the Dandelion++ stem phase propagates txs only to outbound connections.
17:36:51
yiannisbot:matrix.org:
For message propagation, check metrics we have for Ethereum (and other networks): https://probelab.io/ethereum/gossipsub/
17:37:37
yiannisbot:matrix.org:
@rucknium: I would be very interested to look into Dandelion++. I remember reviewing this paper before it was published 😅
17:37:56
rucknium:
You can also check my https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/monero-peer-subnet-deduplication.pdf and rbrunner 's PR https://github.com/monero-project/monero/pull/9939
17:39:01
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
17:41:48
yiannisbot:matrix.org:
@rucknium: But can you not track that through the agent version? 🤔
17:42:04
rucknium:
No :D
17:42:25
rucknium:
Monero is very private. Nodes are shy
17:42:38
rucknium:
They don't tell you their version, deliberately.
17:43:34
rucknium:
Reachable nodes, especially nodes with open RPC ports, can sometimes indirectly tell you by their behavior.
17:43:35
vtnerd:
a hardfork is about the only way to tell
17:43:53
yiannisbot:matrix.org:
I see :) It would be interesting to investigate if there's a way around it, through some heuristics or something.
17:45:48
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.
17:46:18
rbrunner:
Might be would treat such a possibility as something to correct ...
17:46:20
rucknium:
So you can tell if a node is at least updated to a certain version by whether they reject those types of transactions.
17:46:37
rbrunner:
Depending on what it would be exactly
17:47:09
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?
17:47:20
rucknium:
@boog900:monero.social may have more ideas.
17:48:31
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.
17:49:21
rucknium:
I think there is appetite :)
17:49:42
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.
17:49:49
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
17:50:10
rbrunner:
Because it does have some importance
17:51:26
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 :)
17:51:59
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 👍️
17:53:58
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. https://moneroresearch.info/280
17:55:10
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.
17:55:22
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.
17:56:27
rucknium:
Here is the software: https://github.com/ykpyck/monero-traffic-analysis
17:56:27
rucknium:
And my troubleshooting issue: https://github.com/ykpyck/monero-traffic-analysis/issues/1
17:58:09
rucknium:
Anything else on this topic?
17:58:47
yiannisbot:matrix.org:
Not from my end. Thanks for the feedback and the pointers. Let's be in touch in the coming days.
17:59:19
rucknium:
We can end the meeting here. Thanks everyone.
17:59:49
jpk68:
Thanks :)
18:00:16
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. https://moneroresearch.info/280
18:00:16
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.
18:00:45
jpk68:
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
18:01:31
rucknium:
jpk68: Yes, you can bring it up.
18:02:11
jpk68:
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
18:02:23
jpk68:
-- with some changes to the milestones and funding structure
18:03:25
jpk68:
I'm just waiting to hear back from plowsof about some changes to it.
18:03:34
rucknium:
This proposal? https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/650
18:03:43
jpk68:
Yes.
18:04:19
jpk68:
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
18:05:33
jpk68:
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
18:06:54
rucknium:
@vtnerd:monero.social: Do you have thoughts on this? ^
18:06:57
jpk68:
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
18:07:53
rucknium:
Syncing everything over I2P also presents a sybil attack concern.
18:07:55
boog900:
It was the cheapness of generating addresses more than bandwidth that was the concern.
18:08:36
jpk68:
Yes, true. There is definitely more to discuss/consider in that regard
18:09:29
jpk68:
Aside from that specific issue though, I believe it would solve quite a few UX problems with anonymity networks :)
18:10:11
jpk68:
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
18:10:17
vtnerd:
we’ve kept off syncing over i2p/tor because it destroys the limited bandwidth + has eclipse attack issues (ipv4 is naturally a deterrent)
18:11:11
vtnerd:
I thought I2P support was in the GUI? I don’t look at that (the gui) as often as I should
18:11:20
jpk68:
Nope :)
18:11:36
jpk68:
Well, you can configure SOCKS proxies in the GUI, I believe
18:11:46
vtnerd:
I never saw an advantage to the SAM protocol because you still have to know/setup the port for the SAM protocol
18:12:01
vtnerd:
yes, so there is support for it just indirectly
18:12:06
jpk68:
Do you mean from a UX standpoint?
18:12:25
vtnerd:
yes theres still just as much friction, unless you just auto-assume the port
18:12:39
jpk68:
As mentioned in the link below, there is a lot of metadata leakage that can occur with I2P using SOCKS
18:12:40
jpk68:
https://i2p.net/en/docs/api/socks/
18:12:43
vtnerd:
I guess its easier than manually setting up your hidden service address
18:13:13
jpk68:
I2P devs are strongly in favor of deprecating the I2P SOCKS route and using SAM instead
18:13:19
vtnerd:
that disclaimer is for generic usage, not our specific case
18:13:27
jpk68:
vtnerd: Yes, that too. You won't need to manually configure tunnels
18:13:52
jpk68:
I agree with that, however there are many other reasons, as listed here:
18:13:52
vtnerd:
as in, our p2p protocol can still leak metadata even with sam, its not specifically a socks issue
18:13:53
jpk68:
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/454
18:14:30
jpk68:
From the standpoint of I2P nodes, yes
18:14:37
vtnerd:
the only benefit is the auto-creation of services, but with the caveat your still typically setting up i2p + knowing the port
18:15:24
jpk68:
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
18:15:57
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?
18:16:26
vtnerd:
because addresses can be leaked/correlated with other services -> you mean if they reuse an endpoint?
18:17:04
jpk68:
Yes. All applications which use the same SOCKS proxy (as an I2P bridge) share the same destination address
18:17:33
vtnerd:
fwiw Im partially against syncing over I2P as its probably usually a bad idea, but more favorable to supporting SAM
18:18:00
vtnerd:
same destination address? you mean in the reverse direction?
18:18:11
vtnerd:
that sounds like a sh** implementation in I2P to me, but I dunno
18:18:31
vtnerd:
tor just creates tunnels on the fly iirc
18:19:01
jpk68:
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
18:19:15
jpk68:
vtnerd: That's what SAM does, it allows the application to create specific tunnels
18:19:48
jpk68:
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
18:19:50
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
18:20:57
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
18:21:43
jpk68:
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
18:21:47
vtnerd:
and there’s nothing about re-using i2p destination addresses
18:22:02
jpk68:
Thanks for sharing your perspective though, I appreciate it
18:22:24
jpk68:
Again, they share the return address
18:23:10
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.
18:24:12
jpk68:
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.
18:24:17
vtnerd:
I really doubt they re-use connections, or need to for their implementation, but I could be missing something
18:24:32
vtnerd:
yes, if it reduces friction for starting inbound services its probably a win
18:24:34
jpk68:
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
18:24:37
jpk68:
Yes :)
18:25:18
jpk68:
It is also worth noting that the CCS will be changed to a commit/feature-based milestone structure rather than a time-based one
18:25:28
jpk68:
That is in the works, I am just waiting to hear back from some people
18:25:58
vtnerd:
setup the socks correctly? its the same level of difficulty of setting up i2p+sam port
18:26:19
vtnerd:
thats been my complaint - you can basically get everything but inbound working with same level of friction
18:26:40
jpk68:
No, because users will have to use a different SOCKS tunnel for every application to avoid correlation
18:27:15
vtnerd:
….again …. why? each socks tunnel can be a unique i2p tunnel.
18:27:36
vtnerd:
and they never mention this in the writeups, this should be highlighted on that page
18:27:43
jpk68:
Because it's a pain and fixing it would improve UX
18:27:56
jpk68:
I'm not sure what you mean by 'not mentioned in the writeups'
18:28:02
vtnerd:
as in each SOCK connection is a unique i2p connection
18:28:28
vtnerd:
the fact that app A and app B use the same socks port is irrelevant as each connection will be unique anyway
18:28:28
jpk68:
I'm not quite sure, to be honest.
18:28:57
jpk68:
Regarding your last message, again, they share the same destination address
18:29:02
jpk68:
This is still a heuristic
18:29:34
vtnerd:
an example, tor would have massive correlation issues with its exit nodes if SOCKS were inherently this bad
18:30:26
jpk68:
Yes, and this is why I2P devs have never recommended SOCKS for applications like this. You can put any protocol over I2P, pretty much
18:30:28
vtnerd:
I guess I should explain - with SOCKS you only get to make one proxied request. You can’t re-use the connection
18:30:33
jpk68:
That doesn't mean it's going to be good or work well
18:30:55
vtnerd:
so you can’t footgun yourself with SOCKs, except for the issue with privacy within the proxied data
18:31:17
vtnerd:
otherwise tor+socks would’ve been a disaster long ago with its exit nodes
18:31:56
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
18:32:22
jpk68:
Thank you :)
18:32:25
vtnerd:
Im just not convinced that people can setup i2p but not the hidden service element. there’s already tons of friction
18:32:55
jpk68:
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
18:48:58
jpk68:matrix.org:
Not sure why my IRC connection dropped. I'm still here if there are any other questions/concerns :)
20:00:03
vtnerd:
jpk68_looks like i2p uses the same source address for socks, per run, instead of cycling through them like tor.
20:00:37
vtnerd:
if you can hook into SAM to create a new circuit/tunnel per tx-relayed that would definitely be a win
20:01:16
vtnerd:
we may have to randomize when this occurs though, as that too could leak metadata about when a tx is relayed
20:01:46
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)
20:02:04
vtnerd:
although with fcmp++ I guess it doesnt really matter anymore
20:03:43
jpk68:matrix.org:
Yes, for sure :)
20:04:28
jpk68:matrix.org:
That is one of the main research areas in the proposal
20:04:31
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
20:04:45
vtnerd:
can you be more specific?
20:05:54
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.
20:07:04
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
20:09:52
vtnerd:
@jpk68:matrix.org: the ccs proposal doesn’t mention anything about what I’ve just said?
20:15:02
jpk68:matrix.org:
@vtnerd: Have you checked the updated version?
20:15:17
jpk68:matrix.org:
"Decide on ACCEPT vs FORWARD for incoming connections, permanent vs transient destinations"
20:15:27
jpk68:matrix.org:
That's the same thing, no?
20:15:48
jpk68:matrix.org:
Whether or not new tunnels/identities are created per transaction, etc.
20:30:52
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
20:35:51
jpk68:matrix.org:
That could be part of it as well
20:36:51
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
20:37:18
vtnerd:
*transient outgoing -> transient connections/circuits/tunnels, etc
20:40:40
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
20:43:40
vtnerd:
in fact, this is a point against SAM, in practice we want long-lived inbounds to keep the p2p system health
20:44:02
vtnerd:
I’ll just start a discussion on ccs site.
20:49:08
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?
20:55:01
vtnerd:
yes, it should make it harder for nodes to relay to such peers
20:55:49
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
21:01:36
plowsof:
thanks vtnerd