15:01:20 MRL meeting in this room in two hours. 15:04:08 Yu Gao, first author of recent paper ["Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network"](https://moneroresearch.info/267) has joined the room. Welcome, Yu Gao ! 15:04:33 The paper will be the first agenda item of the meeting in two hours. 17:00:15 <0xfffc:monero.social> Hi everyone. 17:00:19 Meeting time! https://github.com/monero-project/meta/issues/1197 17:00:27 1) Greetings 17:00:51 Hello, ALL, thanks for the warm welcome, glad to talk with you here. 17:01:01 Hello 17:01:01 hi 17:01:02 Hello 17:01:05 *waves* 17:01:21 my coauthor is joining also 17:01:42 hi 17:01:43 Yu Gao: Wonderful. Thanks. 17:02:04 Hi 17:02:06 hello 17:02:46 Proposal: when an author join the meeting rucknium should replace "Greetings" section with "MRL. Assemble!" 17:03:00 2) Updates. What is everyone working on? 17:03:05 Hi everyone! 17:03:38 me: mostly lws-frontend stuff, with some odds-and-ends in monerod 17:04:04 Matija Piskorec is also an author of [Gao, Y., Piškorec, M., Zhang, Y., Vallarano, N., & Tessone, C. J. (2025). "Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network".](https://moneroresearch.info/267) 17:04:06 <0xfffc:monero.social> Thanks to help from [boog900](https://matrix.to/#/@boog900:monero.social) I have started working on new tx relay protocol. 17:04:06 <0xfffc:monero.social> Few general PRs on the side. 17:04:22 me: shared analysis on the FCMP++ weight calculation and proposed an algorithm (https://github.com/seraphis-migration/monero/pull/26#discussion_r2057203539), continuing on including the FCMP++ tree root in the PoW hash (after discussions with jeffro, I'm currently working on keeping the tree 9 blocks ahead of the tip i.e. growing the tree with outputs that unlock 10 blocks higher 17:04:22 than the tip which includes normal outputs from the tip block, so that SPV sync via block headers can have solid assurance the latest usable tree root for FCMP++ txs has multiple blocks of PoW on top) 17:05:05 me: Working on the "unit test" of subnet deduplication for peer selection. I have something that seems to be working well for the `white_list`, but maybe not for the `gray_list`. 17:05:57 Also if if a monero twitter account handler is watching, would be good to announce the FCMP++ optimization contest is now open for submissions 17:06:29 jberman: "SPV" means a wallet using a remote node? 17:07:18 It could. It means "Simplified Payment Verification": https://wiki.bitcoinsv.io/index.php/Simplified_Payment_Verification 17:07:26 Here is the link for the FCMP++ optimization contest, by the way: https://web.getmonero.org/2025/04/05/fcmp++-contest.html 17:07:57 * m-relay whispers there is a 95k$ prize 17:08:16 Yes, SPV is usually a term used in BTC-like blockchains. I was wondering how it is explained in Monero. 17:08:49 I mean, you are trying to have nodes "prove" to wallets that they are not being malicious, right? 17:09:25 You could sync block headers, and then verify that the user is spending an output that is a member of the chain by checking it against the FCMP++ root included in the block header (that is PoW-verified) 17:09:39 AFAIK, wallet2 did some checks on the outputs distribution histogram to try to detect if nodes were giving bad distributions for ring construction 17:10:32 Or on the wallet side, the wallet can have stronger assurance the tree it's using to construct the proof is the correct tree (i.e. a malicious node has to provide PoW to feed fake tree data to the wallet) 17:11:18 sounds awesome 17:11:24 Sounds great. Is this related to the issue that tevador found in the current PoW? 17:11:39 I mean, is it a way to reduce/eliminate that issue? 17:11:53 And are you talking with sech1 about it? 17:12:17 Another interesting benefit: a node can sync block headers first, checking PoW, and then start doing verification/tree building in parallel with a solidly optimal construction that maximizes CPU utilization (how I believe evoskuli is doing for Bitcoin) 17:12:32 Not familiar, what issue are you referring to there? 17:12:53 Let's move on to the agenda items. Maybe pick this back up after 17:13:06 3) [Gao, Y., Piškorec, M., Zhang, Y., Vallarano, N., & Tessone, C. J. (2025). "Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network".](https://moneroresearch.info/267) 17:13:31 There was some initial discussion of this paper in #monero-research-lounge:monero.social : https://libera.monerologs.net/monero-research-lounge/20250424#c520278-c520470 17:13:56 And now, thanks to xmrack , we have two of the paper's authors here: Yu Gao and Matija Piskorec 17:14:01 Welcome! 17:14:04 Me and Yu Gao read the discussion that you linked! 17:14:35 Great. Well, how do you want to discuss? Any way is fine. 17:14:55 We are open to answer any questions you might have 17:14:58 We have already read it before 17:16:39 If I recall correctly, the paper wasn't completely clear on whether you were measuring just outbound connections or both inbound and outbound. Of course, one node's outbound is another's inbound, so you can estimate the whole graph, still. But if you wanted to focus on a specific node's connections based only on its data, then you may want to know its inbound connections, too. 17:16:54 So can you directly measure an node's inbound connections? 17:18:23 We regard each "connection" as an undirected link; to detect the architecture is the primary task, and we didn't include the incoming or outgoing detection. 17:19:32 We don't get information about whether a peer is outgoing or incoming from a peer list. So we cannot distinguish between the two 17:20:24 I see. Thank you. Like I stated in the #monero-research-lounge:monero.social discussion, I am skeptical that an adversary could use the topology measurement to harm the network's integrity or privacy because the topology estimate must be taken over a long period of time, e.g. a week. By the time an adversary has that information, it is not useful for malicious behavior. 17:20:43 would the good nodes find each other again in case there is a network shutdown? do you expect the topology to reappear or could it end up differently? 17:21:13 I guess you could rule out incoming by connecting to that peer and seeing if its ports are open, yeah? Would distinguishing between incoming/outgoing make a meaningful difference to partitioning attacks? It might make a privacy difference for Dandelion++... 17:21:34 I agree with this - we have to collect data for a period of time in order to calculate a statistic 17:22:27 i stumbled upon 8 outbound cx you chose. Isn't the default 12 ? 17:22:59 flip flop: I also noticed that. I assume it was a typo (BTC uses 8). 17:24:18 We don't know whether the topology would be identical between the shutdowns. I would assume most probably not. However, this depends on how peers (white and gray lists) are stored in the node between different runs. I guess that these lists can be used to try to reestablish the connections, but it is not guarantied that this will succeed, so topology would probably be different (e specially is enough time elapsed) 17:24:27 My understanding is that, from the graph theory perspective, it is not really a big issue, but of course, from the security perspective, it is meaningful, because it allows incoming connections to pose risks. 17:25:09

Hey Yu and Matija thanks again for joining the meeting. I was wondering if you were aware of the large number of Monero proxy nodes discovered by boog900. Would these “fake” nodes have an impact on your analysis? 17:25:37

Feel free to continue your discussion and come back to my question later 17:25:44 I think some of the in/out measurement depends on what actions, exactly, trigger an update to `last_seen`. Actually, recently I have been investigating how that all works. 17:26:08 I think this is a typo, you are right! 17:26:24 The only way to find out is to observe the network under real stress. Simulations (i've done those) are notoriously hard to do and need to be optimized against real-world case studies. 17:26:24 Would it be feasable to collect data regularily ? 17:26:48 Do these fake nodes play an active role in the network? 17:27:11 From what I understand of the paper, if inbound connections do not trigger an update to `last_seen`, then the method may only be measuring a specific node's outbound connections (but all connections of reachable nodes if this is measured at all reachable nodes). 17:28:18 Yu Gao: It seems that these nodes only accept inbound connections, but do not establish their own outbound connections 17:28:25 They become potential outgoing connections for honest nodes, just like any other node. 17:28:32 There are no reasons to believe that they don't participate in block propagation and consensus requirements. 17:28:58 but yeah, they are just here to grab poor ignorant nodes and weaken tx anonymity. 17:29:02 Info on the suspected malicious nodes: https://github.com/monero-project/research-lab/issues/126 17:29:16 We are continuously collecting peer list data from the three Monero nodes that we are running from various locations 17:30:06 MRL has recommended that node operators ban the suspected spy nodes from having connections to their nodes: https://github.com/monero-project/meta/issues/1124 17:31:01 Network shutdown is a chance for an eclipse attack, they can refresh the peerlist, top grey_list with fake IPs. The shutdown is a base for this kind of attack 17:31:55 There were some recent patches to vulnerabilities that could crash nodes through p2p communication. 17:32:19 don't forget to say it's padillac who found it. I know he want this to be insisted upon. 17:32:31 We were not aware of these fake proxy nodes! Is there a way to identify them? 17:32:47 great question 17:33:18 The method to identify them hasn't yet been made public 17:33:35 Matija Piskorec: Yes. Last MRL meeting, it was loosely decided to disclose the method to detect the nodes once an intermediate countermeasure is written. 17:33:54 Which will hopefully happen in a few months or less. 17:34:10 Looking foreward to the next stressful event... ! Seriously, this data will be helpful. 17:34:18 <0xfffc:monero.social> Until we have counter measures ready, it is naive to disclose the method. 17:34:34 0xfffc tbf there are other methods available 17:35:42 Info about the recent p2p crash vulnerability patches are in the release nodes: https://github.com/monero-project/monero/releases/tag/v0.18.4.0 and HackerOne disclosures: https://hackerone.com/monero/hacktivity?type=team 17:35:50 there is, like active methods 17:36:26 Matija Piskorec: If you look at your data again, these spy nodes should be obvious because they "saturate" their /24 IP address subnets. 17:36:34 We don't yet have a plan to publish this data. It would be technically challenging (it's GBs of data). But we are open for suggestions and collaboration! :-) 17:36:46 Xmr used to use 8 17:36:54 That suggests that a malicious party is renting whole /24 subnets to run proxy nodes 17:37:13 ofrnxmr: Do you know when that changed? 17:38:20 Matija Piskorec, Yu Gao : Do you plan to present this paper anywhere at a conference soon? 17:38:22 Thank you for the suggestion! In the future we might decide to exclude them. 17:38:24 Can you expand on this scenario ? 17:39:04 Yu Gao: is presenting in on IEEE ICBC conference in Pisa, 2-6 June. https://icbc2025.ieee-icbc.org/ 17:40:58 Matija Piskorec: Well, maybe still include them and write a narrative about them or something. You could elaborate a lot about the facts you found, if you want to speculate a little. On a related topic, you found "supernodes" with very high number of connections (different from the spy nodes that boog900 discovered. As you know, this paper also found that supernodes existed: [Gao , Y., Piškorec, M., Zhang, Y., Vallarano, N., & Tessone, C. J. (2025). "Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network".](https://moneroresearch.info/267) 17:41:09 Great! 17:41:14 This is another research idea I am going to simulate, but it is very early stage, maybe I will share it in the future? 17:42:39 I wonder if the supernodes are nodes of mining pools that want to propagate their blocks as quickly as possible. Or other honest services. Or they could be trying to spy, but Dandelion++ is designed to defend against supernodes since the stem phase propagates txs to outbound connections. 17:43:11 is there the possibility to implement a reputation system to prevent these kinds of eclipse attacks? It seems like using ips to make it expensive to run fake peers is duct tape. would be a great research topic 17:43:31 Rucknium: I am also going to your MorKon5 workshop. 17:43:41 2020 https://github.com/monero-project/monero/commit/c67fa324965268cd1c01cbcb513038e7344f35d1 17:44:46 Fantastic. I will be presenting there, too, but remotely. 17:44:56 i have some ideas regarding WoT -- last agenda item. 17:45:17 WebOfTrust? 17:45:18 <0xfffc:monero.social> Videos will be available immediately? 17:45:21 Thanks. I actually thought the number of connections change was earlier 17:47:05 0xfffc: My videos will be available immediately since they will be pre-recorded and available on Vimeo (or possibly another public site). I think MoneroKon organizers need some time to post edited versions of most in-person presentations. You can ask in #monerokon:matrix.org for more info. 17:48:28 boog900 has suggested that the default number of outbound connections could go even higher if and when a more bandwidth-efficient tx relay protocol is implemented. 0xfffc said at the beginning of the meeting that he was working on it. 17:48:47

Yu Gao: maybe I missed it but did you publish the list of super node IP addresses? 17:48:58 no 17:49:33 We totally understand the responsibility of analysing DLT networks. 17:49:36 Here is the new tx relay proposal: https://github.com/monero-project/monero/issues/9334 17:49:41 A higher number would probably improve a majority pruned-node environment, but w/o tx-relay improvements, it adds a lot of latency 17:49:46 <0xfffc:monero.social> Yes. Boog is implementing for cuprate. I have started monerod tx relay 17:49:46 <0xfffc:monero.social> Let me find the links 17:49:58 Theres also in-progress code for this 17:51:13 The main problem with increasing outbound is putting a bottleneck on the minority nodes who accept incoming connections 17:51:41

Yu Gao: would you consider disclosure of the super node IP addresses to the Monero VRP via hackerone? 17:52:41 In a network where only 1/10 nodes have incoming connections, the singke node has to handle all of the traffic. We set incoming to unlimited by default, bur in practice most node will bottleneck-out at 100-1000 connections, depending on network haedware, operating system, and uplink speed 17:53:17 <0xfffc:monero.social> [Rucknium](https://matrix.to/#/@rucknium:monero.social) 17:53:18 <0xfffc:monero.social> Cuprate: 17:53:20 <0xfffc:monero.social> https://github.com/Cuprate/cuprate/pull/407 17:53:22 <0xfffc:monero.social> Monerod: 17:53:24 <0xfffc:monero.social> https://github.com/0xFFFC0000/monero/pull/60 17:53:26 for the record, in a stress situation, less cx will be more resilient (in all likelyhood) 17:53:43 So increasing outbound is, imo, abbad idea at a certain point. Cant use up "all" of the incoming slots by abusing our outbound connections 17:54:23 In principle we are open to disclosing any information (data, code) related to our paper to the Monero team. 17:55:03 The paper says, "Our results show that the network is highly centralized around several super nodes with significant betweenness centrality and high degrees. While this centralization strengthens security and robustness, it also introduces potential vulnerabilities." 17:55:04 Technically, yes the graph metrics would show more centrality when a few nodes decide to set a high non-default number of outbound connections. However, is it centralized in a meaningful way? If the supernodes didn't exist, would the network be in a better or worse state? 17:55:06 i assume the supernodes are what i am referring to. Most non-supernodes are exhausted much more easily 17:55:16 Increasing outbound connections exacerbates this problem 17:56:22 <0xfffc:monero.social> Skimmed the paper, my questions too 👆🏻 17:56:24 (Even with improved tx-relay) 17:57:09 If the supernodes didnt exist, the question is: do the remaining nodes have enough inbound slots to service the nerwork 17:57:10 I'm not saying we should wack the number of connections stupid high, but with the new protocol reducing bandwidth usage by 75%+ we could double the number connections and still be using less bandwidth overall (assuming linear growth which isn't the case with the new protocol, it should be less). 17:57:54 Bandwidth isnt the bottleneck here, its the number of inbound connections available to the network 17:58:14 IIRC, there have been a couple of papers that worry that BTC's default 8 outbound connections is too low. 17:58:23 The view needs to be dynamic and individualistic. nodes may decide for themselves (UI?) 17:58:28 In would assume that less than 50% kf nodes on the network are reachable via incoming due to nat, shared ip, etc 17:59:01 I uploaded 41 GB over 11 hours today on an unrestricted node. So not sure about " Bandwidth isnt the bottleneck here" ... 17:59:28 rbrunner: found the supernode operator :P 17:59:44 Lol 17:59:47 what is an "unrestricted node"? 17:59:58 It depends on how we define centralisation. If the nodes have a lot of connections, for instance is the mining pool nodes, then it has super computing power and an advantage to get more rewards, something like this, and also if the super nodes shut down, the network is easily disconnected 18:00:03 No limits on number of incoming, no speed limit 18:00:19 and is your rpc public? 18:00:25 No 18:01:05 41gb isnt a lot. Its like 1/4 of a node syced from you 18:01:21 i highly doubt the 42gb is due to txrelay 18:01:41 <0xfffc:monero.social> > and also if the super nodes shut down, the network is easily disconnected 18:01:42 <0xfffc:monero.social> I have problem with this part. I can’t imagine what kind of network / graph is that. 18:02:21 thats hard to predict. 18:02:24 Its because most nodes dont have incoming connections, so those nkdes _must_ make their connections to those who do, leading to centralization around the ones that do 18:02:28 how many connections rbrunner? on average doesn't have to be exact 18:02:47 100 or so 18:02:52 If 80% of the connections on the network are directed at supernodes, that implies that the rest of the network's incoming is likely exhausted 18:03:33 Yu Gao: Matija Piskorec : By the way, MRL has powerful scientific computing hardware if you ever did want to share data with MRL so that MRL researchers could look at it, too. Or if something needed a lot of RAM and threads. 18:03:54 I believe a general node would not intentionally modify its config file to get a lot of connections. 18:04:05 One machine with 256GB of RAM and another with 1TB of RAM. 18:05:02 Current impl of the node node picks more-recently-succeeded outgoings with high probability, so perhaps the network strongly coalesces around nodes which have high uptime 18:05:05 About 100 inbound connections on nodes with open ports is very common, AFAIK. 18:05:55 Yu Gao: By default, Monero nodes accept an unlimited number of inbound connections. 18:06:32 My opinion is that centralization is a bit ambiguous word - we can measure centrality in many different ways. And of course, more or less centralization is not necessarily a good or a bad thing, because it affects the network in different ways. So it's hard to say whether removing the supernodes would make the network better or worse. 18:07:28 <0xfffc:monero.social> [ofrnxmr](https://matrix.to/#/@ofrnxmr:monero.social) 18:07:48 it would slow down the network, but consensus may be robust. The spam attack hints at that. Future will tell. 18:09:13 it would slow down the network, but consensus may be robust. The spam attack hints at that. Future will tell. 18:09:14 Unless a bad actor takes advantage of the situation... i think i get your idea. 18:09:35 This is under 10Mbps. It does indicate that upstream bandwidth can be a limitation 18:10:03 But inbound connections can be a burden for a general node? 18:10:16 from my data in 9334 I would expect about 10GB of that to be tx-relay FWIW 18:10:48 the rest is probably a node syncing 18:10:55 Yu Gao: Yes. In the suspected tx spam attack last year, many nodes had big problems because too many txs and too many conenctions. 18:12:25 That is a reason why a Monero "stressnet" was organized last year. A large number of txs were spammed to test problems and correct them. 18:12:33 Not if they are behind a nat etc, and in practice that is limited by uplink speed and network hardware or os (anywhere from 10-1000 connections) 18:13:20 It can be if they are in a cable as opposed to fibre Internet connection. This is because of the mindset of the cable tv companies 18:13:26 I have to go now, but thank you everyone for your questions and interest in our paper! You can always reach us via email (they are in the paper) if you have any additional questions or you want to discuss potential collaboration 18:13:29 Upnp rarely works in my experience, meaning that unless a user manually enables port forwarding, their node does not have incoming. 18:13:40 IMO we can double the number of outbound connections with the new relay protocol and still be fine, if individual nodes need to limit connections they should be doing that already. 18:13:51 Imo we should definitely not 18:14:16 Here is info on what happened on the stressnet: https://www.reddit.com/r/Monero/comments/1eoana8/the_stressnet_so_far/ 18:14:16 if that is enough to kill the network then the network is more at risk now with the current protocol and connection count 18:14:20 Not without knowing how many non-superpeer nodes have incoming connections 18:14:20 Thank you! 18:14:28 sorry Rucknium, I also need to go now. Thanks for reaching out; it's a pleasure to join here, and the great discussions. Feel free to connect with us by email. 18:15:06 Matija Piskorec: Yu Gao Thank you very much for discussing here! I think we will be in touch. 18:16:57 Its a very simple problem. If there are 150 network participants, but only 10 of them have incoming connections, and limited to 100 connections each = max 1000 incoming connections can be served. If the other 140 nodes have 12 outgoing connections, that is 1680 outgoing slots to fill. 18:16:59 <0xfffc:monero.social> Why are you saying that? With new tx relay protocol, what’s the problem? Once new tx relay kicks in, the bandwidth usage almost halves 18:17:07 For example here in British Columbia Canada, the Telco offers up to 3 Gbps symmetrical and in some cases 5Gbps symmetrical. The Cable co maxes out at 200 Mbps upstream and in most cases much lower 18:17:14 This isnt about bandwidth, its about slots 18:17:59 <0xfffc:monero.social> No, my point was, I don’t see issues doubling slots when we reduced bandwidth usage 18:18:11 You're not doubling incomibg slots 18:18:25 Youre doubling the amount of incoming slots that are used up 18:19:06 move on ? 18:19:11 Instead of 1680, now those 140 nodes are trying to hold 3360 outgoing connections against 1000 available incoming slots 18:19:43 Nodes with open ports have a strangely high number of inbound connections. If there are no supernodes with non-default outbound conenctions, then about 90% of nodes are unreachable. But probably there are supernodes. 18:20:43 There are a couple more agenda items. 18:21:42 web of trust, web of trust (if you chant it, it sounds a bit like one of us, one of us) hyped for this topic as it seems to be at the bottom of all of this 18:22:03 We have to distinguish here between initial node synchronization and ongoing node relay. Nodes with closed ports still have to deal with ongoing node relay 18:22:16 4) FCMP++ transaction weight formula. https://github.com/seraphis-migration/monero/pull/26 18:22:56 jberman and jeffro256 are working on the requirements for this. They have been discussing in #no-wallet-left-behind:monero.social 18:23:57 Transaction weight is used for the dynamic block weight algorithm and tx fees. 18:24:07 my latest analysis on FCMP++ tx weight formula is here: https://github.com/seraphis-migration/monero/pull/26#discussion_r2057203539 18:24:41 <0xfffc:monero.social> Honestly, if we would’ve opened a separate repo for FCMP++ migration would been much more clear. I still have problem understanding what is going on. We do FCMP++ under seraphis migration, we used to have seraphis as protocol. Now we are doing FCMP++ 18:26:59 The clawback was implemented to account for verification time with l6 outputs. It is overkill when we are limiting the number of outputs to 8. So I would recommend against it 18:28:00 <0xfffc:monero.social> ( anyway, not wanna hijack the topic ) 18:29:57