The MRL reviewed the revised CCS proposal from ProbeLab for P2P network metrics collection and analysis (repo.getmonero.org/monero-pr…). Discussion focused on clarifying terminology from the Dandelion paper: the proposal’s reference to “spy nodes” was corrected to “unreachable nodes,” as the original paper ignores unreachable nodes in its anonymity analysis while spy nodes were explicitly part of it. Rucknium stated the revised proposal looks good and is ready for the community room. rucknium: 7. CCS proposal: ProbeLab P2P Network Metrics Proposal (repo.getmonero.org/monero-pr…) yiannisbot: rucknium: Hi everyone, here to answer any questions regarding the proposal. I hope people had the time to look through the updated proposal, although I didn't see any new comments in the issue. rucknium: yiannisbot: Hi. Thanks. I think there was a misunderstanding about terminology. I said before that the Dandelion paper ignored unreachable nodes. You said in your revised proposal that they ignored spy nodes. Just change that to unreachable nodes. Spy nodes are very reachable. Being reached is their main purpose :) rucknium: I think the proposal looks good in its revised form. The exploratory research is risky, but that is usually the case with research. I mean risky in terms of uncertainty about the outcome. yiannisbot: rucknium: 😅 Of course, apologies. Wrong phrasing. I'll change that. rucknium: I would change moneronet.info to xmrnetscan.redteam.cash in the proposal. rucknium: ofrnxmr, boog900 : Do you have comments on ProbeLab's proposal now that you have had time to digest the revisions? vtnerd: my only comment was to re-iterate what someone else said: “he Dandelion paper assumes that spy nodes do not play a role and therefore ignores them in the analysis.” -> I assume this was meant to be unreachable nodes? vtnerd: spy nodes were definitely a part of their analysis iirc fireine: vtnerd: what is a reasonable definition for a "spy node" boog900: rucknium: I think it's ok yiannisbot: vtnerd: Yes, definitely, apologies, this was my fault. vtnerd: yeah which is minor because I guessed based on context it was a typo boog900: fireine: A node trying to link IPs to txs. fireine: boog900: what if the node operating a "spy" service without its knowledge. how can we identify or tag them as a "spy node" fireine: meaning the service running on such node is linking IPs to txns and not the runtime itself rucknium: They would have to know. Spying is deliberate and involves active aggregation of information. fireine: rucknium: what if it's mythos, for example fireine: or an adversarial ai rucknium: The main model of spy nodes is explained in the D paper. One moment. rucknium: moneroresearch.info/122 Fanti, G., Venkatakrishnan, S. B., Bakshi, S., Denby, B., Bhargava, S., & Miller, A., et al. (2018). Dandelion : Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees. Proc. ACM Meas. Anal. Comput. Syst. 2(2). fireine: cnbc.com/2026/06/01/anthropi… rucknium: I think the ProbeLab proposal is ready to go to #monero-community:monero.social fireine: I think anthropic peeps are mostly weird. so laugh at their models too. but still. something to consider rucknium: Any more comments on this item? jpk68: fireine: Whether or not it's run by an AI is completely irrelevant. A spy node is a spy node libera.monerologs.net/monero…

CCS proposal: ProbeLab P2P Network Metrics Proposal. repo.getmonero.org/monero-pr…

ProbeLab representatives (yiannisbot and dennis_tra) presented a revised CCS proposal that drops Milestone 1 (general metrics and dashboards) and sharpens focus on Milestone 2: quantifying spy node impact on Monero’s P2P network connectivity and exploring mitigation strategies. Community feedback, particularly from boog900, stressed incorporating existing Research Lab issues (#160 on proving connections and #126 on related ideas) and shifting emphasis toward concrete solutions rather than restating the already-recognized spy node problem. The proposers welcomed the input and committed to reviewing these threads for inclusion. jberman: 7. CCS proposal: ProbeLab P2P Network Metrics Proposal. ( repo.getmonero.org/monero-pr… ) yiannisbot: Hi everyone myself and dennis_tra are around. dennis_tra: Hi everyone yiannisbot: We've received feedback from the community during the last few MRL meetings and have revised the proposal. yiannisbot: Consensus seems to have been that Milestone 1 on general metrics and dashboards should be removed from the scope of the project and instead focus on Milestone 2. We've revised the proposal accordingly and expanded the scope of Milestone 2 with more details. freeman: luke: When he thinks your proof is elegant jberman: ofrnxmr, sgp_, boog900, do you guys have further thoughts on the updated proposal? Apologies I haven't been following this item closely luke: Unironically, it might be one of the nicest proofs I have ever seen. All the pieces just smoothly fit together. boog900: > We will try to quantify how big of a role do spy nodes play. The Dandelion paper assumes that spy nodes do not play a role and therefore ignores them in the analysis boog900: I am not sure I understand that ofrnxmr: jberman: It was just updated abt an hr ago boog900: The whole point of D is to minimize the spying ability of spy nodes yiannisbot: boog900 : Yup, at this stage and given we're not going to analyse the D specifics (e.g., message propagation), we're going to look at how spy nodes affect the network from a connectivity point of view as a first step. yiannisbot:matrix.org: This particular recommendation was originally from rucknium jberman: o ems people could use more time to grok/weigh the updated proposal boog900: IMO I would want the proposal focused on investigating solutions, so I like the few points focused on that yiannisbot: jberman : Sure, but also, I'd suggest to contribute to the issue so that we make faster progress ;-) boog900: I don't know if you saw, but I made an issue for proving connections: github.com/monero-project/re… boog900: tevador also gave a proposal in there too boog900: it would be good for those to be included in the analysis yiannisbot: I didn't see this - thanks for the pointer. Regarding solutions: we don't know which solution would work at this stage, so it's difficult to list it. If the community has clearer view, please share and we can focus our investigation accordingly. But it doesn't seem to be the case from what I gather the past few months we've been looking into this. In any case, our study will be solution-based, e.g., with better heuristics to identify spy nodes. yiannisbot: boog900: Let me have a look at the details and will get back to this thread and/or add it to the proposal. sgp_: I also don't fully understand the comment here, but overall I think the changes are in the right direction > <boog900 > > We will try to quantify how big of a role do spy nodes play. The Dandelion paper assumes that spy nodes do not play a role and therefore ignores them in the analysis jberman: Thank you guys. Feel free to keep discussing. I'll close the meeting here boog900: yiannisbot: We have had a few ideas: github.com/monero-project/re… and that link I just sent. boog900: But if we knew what would work we wouldn't need to investigate boog900: The reason they are still here is we don't know how to get rid of them sgp_: Mandatory kyc to run a node, ez /s yiannisbot: boog900: Exactly, that's what we also want to investigate. But we also don't have a solution off the shelf boog900: That's fair, but then I don't think we need more research to tell us we have a problem yiannisbot: boog900: But this way the problem will just remain, no? boog900: I mean we already know we have a problem yiannisbot: Sure, we don't plan to do a study to confirm there's a problem. We'd like to get closer to a solution, or ideally find a solution. If there's no research around it then it will just continue to be a problem. libera.monerologs.net/monero…

CCS proposal: ProbeLab P2P Network Metrics Proposal. repo.getmonero.org/monero-pr…

yiannisbot presented the updated ProbeLab CCS proposal direction: community consensus favors skipping Milestone 1 (dashboard) and focusing on Milestone 2 - statistical estimation of unreachable nodes plus improved heuristics to detect spy nodes and surveillance entities, including PoW-system investigation. The proposal will be revised and brought back next week. rucknium: 5. CCS proposal: ProbeLab P2P Network Metrics Proposal (repo.getmonero.org/monero-pr…). rucknium: yiannisbot said he would arrive to the meeting at 18:00 UTC. In 6 minutes. yiannisbot: Hi everyone, I'm here :) yiannisbot: The general feeling of the community seems to be that we skip Milestone 1 and focus on Milestone 2. We won't only count unreachable nodes, but try to find better heuristics and derive insights that would help identify spy nodes and blockchain surveillance companies. We will also spend some time to investigate if POW systems would be a viable approach, primarily based on previous research. If diving into monerosim for some POW investigations, we'll consider doing that, but I don't think we will commit to that. yiannisbot: Does that sound like a good summary? We plan to update the proposal issue to reflect these new directions. Any extra feedback is more than welcome as we try to shape up the final version. yiannisbot: rucknium: plowsof what's your take and suggestions for next steps? rucknium: That sounds good to me. Right, I think one would use monerosim when you are ready to actually implement a feature into the monerod C codebase. Initial research on the viability of a PoW approach would come before that. rucknium: boog900 had some recent thoughts about spy node countermeasure that he may want to post here. yiannisbot: Exactly. So if while doing the study we come up or identify a previously proposed approach that looks attractive, we can then port it into monerosim. rucknium: More comments on this item? (I see someone typing) vtnerd: For #2 (unreachable nodes) you kind of have to do the work if #1 anyway? Just no fancy dashboard? boog900: I had an idea on how we could prove nodes were not making too many outbound connections but it would require something like proof of storage. If we could do that though then we might be able to allow stemming to inbound connections, which would increase the stem graph and remove the privacy leak when nodes don't allow inbound. yiannisbot: Yeah, kind of. That's why we included it as a first item/milestone. But given M1 is not desired we'll do just what is needed to be able to get to M2. boog900: It's pretty cheap to tag on with proof of storage though rucknium: To get unreachable nodes, you take a different approach. You have to passively wait for nodes to connect to you. To get reachable nodes, you can just crawl rapidly through peer lists, connecting briefly to each reachable node. To get the ratio of reachable to unreachable, of course, you would do both. rucknium: Or there may be a smarter way to get unreachable node count, but I don't know of one. vtnerd: the primary value of unreachable node estimation is in d privacy related. Is that the consensus? Because funding the research for that makes sense yiannisbot: vtnerd: Agreed, but to me that would be the natural next step. rucknium: vtnerd: Yes yiannisbot: boog900: That's a good approach. We'll take this into account as we revise the methodology for Milestone 2. boog900: I feel Milestone 2's scope is getting large. rucknium: Paraphrasing, the D papers said that unreachable nodes don't play a large role in the network, so they are ignored in the analysis. We could show that unreachable nodes do play a big role in the network, at least by the number of nodes. rucknium: I am trying to find the quote. They don't use the term "unreachable" rucknium: Can't find it at the moment. rucknium: We can end the meeting here. Thanks everyone. yiannisbot: Thanks. We'll be back next week with an updated proposal for Milestone 2 and hope to make progress from there. libera.monerologs.net/monero…

CCS proposal: ProbeLab P2P Network Metrics Proposal. repo.getmonero.org/monero-pr…

MRL reviewed the ProbeLab CCS proposal for P2P network metrics. M1 (dashboard) received negative community feedback and is likely to be dropped. Discussion focused on M2: statistical estimation of unreachable nodes with confidence intervals (preferred mathematical derivation or Monte Carlo/bootstrapping rather than brute-force node deployment). Rucknium emphasized using ProbeLab's expertise for rigorous estimators, avoiding cost bloat and privacy concerns from large-scale node setups. yiannisbot agreed to refine M2 with confidence intervals and seek broader feedback (including from network devs). Budget (~113 XMR) and AGPL licensing were noted; further community input needed before advancing. rucknium: 6. CCS proposal: ProbeLab P2P Network Metrics Proposal (repo.getmonero.org/monero-pr…). rucknium: The CCS system is back up. Thanks for everyone who helped get it working again: repo.getmonero.org/monero-pr… rucknium: In the last discussion, a few people were not happy with the part of the CCS that was a monitor dashboard, similar to xmrnetscan.redteam.cash/ yiannisbot: Yup, correct. boog900: oh wow look at the new nodes in the last few days boog900: so much adoption rucknium: plowsof is working on a better DNS-based blocklist that could contain more addresses: github.com/monero-project/mo… yiannisbot: The dashboard would give more insights regarding the new nodes, but indeed there was some disagreement from the community to proceed with this. yiannisbot: By "this", I mean Milestone 1 of the proposal. plowsof: thanks for sharing, after review comments from iamamyth im moving to obtaining a url:hash for the ban list and applying it directly. same effect none the less boog900: I don't think it would give us much more insight, we pretty much know that 1000 real nodes did not come online overnight yiannisbot: Agreed. So AFAIU, the community is in favour of dropping M1 from the proposal and moving on with M2 - is that correct rucknium ? rucknium: I think M1 has received negative feedback. M2 needs more feedback. jpk68: The XMR/EUR exchange rate is a bit off rucknium: For M2, you would probably want to get an estimate of how frequently nodes rotate peers. I had some rough results here: github.com/Rucknium/misc-res… rucknium: Line 329 - 349, pages 20 - 21. And Figure 14 rucknium: If you were to do M2, I would want to have a confidence interval on your estimator for the number of unreachable nodes. I don't really want you to solve the estimation problem by setting up hundreds of nodes (or proxies) and get a good estimate by brute force. rucknium: So you could derive the confidence intervals mathematically (ideal, but difficult) or do Monte Carlo and/or bootstrapping to get the confidence intervals. yiannisbot: Sure, but out of curiosity, why would this not be desired? yiannisbot: > I don't really want you to solve the estimation problem by setting up hundreds of nodes (or proxies) and get a good estimate by brute force rucknium: Bloats your costs. Bloats MRL's costs if it wants to take samples over time. And deploying that many nodes and collecting all the data together is like spying on users. rucknium: The task is to use mathematics to get the estimate. Throwing more infrastructure is...not difficult enough! rucknium: We want to use your expertise. Not just have SaaS (software as a service) rucknium: I should say I want that. I shouldn't speak for others. yiannisbot: I see, yes. I think a combination of both would be ideal. If costs are unbearable, it could be that deploying nodes could be done once a week/month/whatever. rucknium: You should be able to express the confidence interval as a function of the number of nodes you need to deploy. Then make a decision about how many nodes would give you an acceptable confidence interval. yiannisbot: Is it recommended then to add the following statement in M2 of the proposal? yiannisbot: > So you could derive the confidence intervals mathematically (ideal, but difficult) or do Monte Carlo and/or bootstrapping to get the confidence intervals. rucknium: Yes. I think so. yiannisbot: And then bring the topic back here next week? Or what's the process going forward? rucknium: I try to get more people involved in Monero research instead of being greedy with tasks that are in my area. yiannisbot: Not sure I'm getting this :) rucknium: yiannisbot: You need more feedback on Milestone 2. yiannisbot: WDYM? yiannisbot: Sure, how can we make that happen? Are there people here that we can bring into the discussion? rucknium: I am a statistician (actually, economist with empirical focus) and therefore proposing and exploring the properties of a statistical estimator is in my area. But I don't want to lay claim to a task just because it's in my area. Anyway, there is much more research on Monero stats than I can do alone. rucknium: ccs.getmonero.org/how-to-ccs… rucknium: > 7. You're done. Now go drum up some support. Good job on getting all the way here. When you finish, the community will be discussing your proposal on the merge request itself. If you want to weigh in on the discussion, feel free. It will be up to you to get people to support your proposal, both for it to be moved to the Funding Required stage, and also while its awaiting donations. boog900: I think 113 XMR is quite a bit for this task ngl. boog900: Is that the amount it'll be? rucknium: We're 1:45 into the meeting. I will end the meeting here and discussion on topics can continue. Thanks everyone. yiannisbot: The amount is estimated to be about that, yes. We'll revisit though once we have the full feedback of what is desired here. yiannisbot: Rucknium gave some constructive feedback on the direction. yiannisbot: Yes, I suspect that this is the most likely feedback we're going to get. So in order for this to go forward, it will need feedback from a few technical people. That's what we've seen generally. So if you know people that would care/appreciate this kind of work it would be great to talk to them (during this meeting or elsewhere). rucknium: Those people would probably be boog900 , vtnerd , syntheticbird , ofrnxmr , sgp_ , plowsof rucknium: And articmine rucknium: (If I didn't mention you and you think I should have, now is your time to speak up and comment!) rucknium: rbrunner could comment, too, since he wrote the anti-spy subnet deduplication code. ofrnxmr: Is the current plan to gpl / foss any work? I need to re-look at m2 yiannisbot: Yes. We agreed in the previous meeting to go with AGPL. Let us know thoughts. yiannisbot: Thank you! Message to those folks: please contribute ideas to the discussion, either here, or in the Lounge or in the proposal repo itself. I think this would speed things up quite a bit. libera.monerologs.net/monero…

CCS proposal: ProbeLab P2P Network Metrics Proposal. repo.getmonero.org/monero-pr…

The MRL discussed ProbeLab’s CCS proposal for a P2P network metrics dashboard/monitor focused on Monero’s Dandelion (D ) performance in adversarial environments, particularly spy nodes, community ban lists, and blockchain surveillance (BS) companies. boog900 opposed the proposal in its current form, arguing that D behaviour is already sufficiently understood from academic papers and recommended focusing research instead on increasing the cost of spy nodes or eliminating them. yiannisbot (ProbeLab) advocated for the dashboard’s value in providing real-world risk quantification and publicly exposing BS company activity, while remaining open to reducing scope to Milestone 2 only. rucknium highlighted the risks of open-ended research and referenced multiple relevant papers and simulations. No consensus was reached. rucknium: 7. CCS proposal: ProbeLab P2P Network Metrics Proposal ( repo.getmonero.org/monero-pr… ). plowsof: can be accessed via this snapshot web.archive.org/web/20260502… rucknium: Thanks, plowsof . rucknium: Last time sgp_ suggested "I think we need research on how dandelion works in an adversarial environment, with the presence of a community ban list that X% of honest nodes use and is Y% effective at fingerprinting adversarial nodes" gingeropolous: seems like a reasonable thing for monerosim rucknium: I wonder if there is much work involved to do that. The D paper showed, theoretically, that the recall that the adversary can achieve is p and the precision is p^2, where p is the percentage of spy nodes in the outbound connections of the targeted node(s). rucknium: monerosim could definitely be helpful with that, if it were to be done. rucknium: Also, the Clover paper empirically measured D efficacy with a closed bitcoind testnet. gingeropolous: im finding scale is the issue. though i guess it could just be 1 user sending transactions amidst a network of mostly monerods., not the 1k users (monerods and wallets) i for some reason have set the bar at rucknium: moneroresearch.info/222 Franzoni, F., & Daza, V. (2022). Clover: An anonymous transaction relay protocol for the bitcoin P2P network. Peer-to-Peer Networking and Applications, 15(1), 290–303. rucknium: Section 7.3, page 12 rucknium: Measuring the effectiveness still does not solve the spy node issue, which is the ultimate goal. yiannisbot: Hi folks, back online and available now. Great there is a mirror for the proposal - I was not aware. rucknium: Can I assume that boog900 does not want to comment about the proposal (or is just not checking pings in this room at this time)? rucknium: A simulation could discover a problem with monerod's implementation of D if it existed, however. AFAIK, there hasn't been a realistic test of the actual implementation. yiannisbot: Based on monerosim you mean? rucknium: Yes. monerosim would be the obvious platform for a test like that. rucknium: Code at github.com/Fountain5405/mone… yiannisbot: Yeah, it could be a good first step. Although I think that a real-world test would help - maybe as a second step. yiannisbot: A few things that we've been thinking about regarding D are: if spy nodes can dominate or distract message propagation (before they're added to the ban list), what is the risk threshold of privacy guarantees for ban list adoption. I was also wondering what's the efficiency of "fluff timer" efficiency, e.g., if a malicious node triggers dissemination by default it would flood the network with more traffic and might overload nodes. yiannisbot: But rucknium as you said, the spy node issues we've put in the proposal would come first IMO. boog900: Sorry, I thought I had given some thoughts on it, but I don't support the proposal in its current form. I don't see that much value in a second network monitor. boog900: I think we already have a pretty good idea of how D performs from the paper. I would rather research on how to stop spy nodes all together, maybe looking at how to further increase their costs. rucknium: Thank you, boog900 yiannisbot: > we already have a pretty good idea of how D performs from the paper yiannisbot: What ratio of spy to normal nodes did the paper investigate? I can't remember. Is that close to what we found at: probelab.io/blog/peering-int… ? articmine: One important aspect of the spy node issue is the role of blockchain surveillance (BS) companies in setting up these spy nodes, and the use of spy nodes to obtain personally identifying information from wallet users by deceit. This was discussed in a leaked video. boog900: yiannisbot: they had graphs which plotted performance against fraction of spies articmine: More fundamentally, what is the important problem that this dashboard is going to solve? Why do we need one so much so that the community should crowdfund for one? yiannisbot: Exactly and that's why I think a risk threshold study would be important. articmine: One of the key elements I see in this dashboard is publicly exposing the BS company behaviour articmine: In my view both the study and the dashboard is needed rucknium: yiannisbot: I don't know what you mean by your question. The theoretical formula works for any ratio of spy nodes. I looked at the D paper recently again. They used a modified bitcoind on bitcoin mainnet, but for tx propagation speeds instead of estimating spy resistance. The D paper had plenty of python simulations for numerical estimates for the spy effects, however. rucknium: The Clover paper used actual bitcoind for a private testnet simulation to record the spy node effects (for Clover and D ). There is another paper that just did simulations that I will pull in a minute. rucknium: moneroresearch.info/130 Sharma, P. K., Gosain, D., & Diaz, C. (2022). On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies. arXiv. rucknium: The Sharma, Gosain, & Diaz paper was about learning the private D graph. More complicated and difficult for an adversary to achieve. boog900: I feel the result of any research on spy nodes is just going to be "spies bad". boog900: Even if we say the privacy impact is 0, just the impact on the security of the network is enough to warrant research into how to prevent them. boog900: so why not just skip to step 2 and work out how to get rid of them. rucknium: I shall end the meeting here since we are 30 minutes past the hour, but everyone should feel free to continue discussing any topic. rucknium: boog900: Would you suggest that research be put into something like this, but with fewer downsides? ieeexplore.ieee.org/document… yiannisbot: I obviously feel that the dashboard would be valuable and I can't see anywhere the metrics we published on the blogpost, but happy to skip that part for now and proceed with Milestone 2 only for now. rucknium: The problem with open-ended research is that at the end, possibly nothing useful will come out of it. It's risky. rucknium: ieeexplore.ieee.org/document… citation is J. W. Heo, G. Ramachandran and R. Jurdak, "PPoS : Practical Proof of Storage for Blockchain Full Nodes," 2023 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), Dubai, United Arab Emirates, 2023, pp. 1-9, doi: 10.1109/ICBC56567.2023.10174897. boog900: If they still pay the full storage cost if we impl PPoS then we are out of options really, as they would have the resources to run real nodes. rucknium: No. "work out how to get rid of them [spy nodes]" is the open-ended path yiannisbot: Do you refer to Milestone 2 of the proposal as open-ended? I would see a clear outcome out of it with recommendations and proof. boog900: Yes I do think PPoS or something Proof-of-Storage-esque is going to be the solution for spy nodes rucknium: I asked the lead author of the D paper about how to get rid of spy nodes and she didn't have any great ideas. rucknium: That's in a previous MRL log from about a year ago IIRC articmine: I agree with "so why not just skip to step 2 and work out how to get rid of them." I suggest that not only should we consider technical countermeasures, but social and even set the stage for legal countermeasures should one or more members of the community wish to go that route. boog900: If they still pay the full storage cost if we impl PPoS then we are out of options really, as they would have the resources to run real nodes. rucknium: This is an example of a research effort that did not produce the intended results: "Research to Defeat EAE Attack and Analyze Effectiveness of Churning Procedures" donate.magicgrants.org/moner… boog900: At that point we would need to look at being a permissioned network, for tx-relay at least rucknium: Reasonably, PoW is probably out of the question because it would hit honest nodes too hard. rucknium: But cutting-edge research is often risky. boog900: yeah I think so too yiannisbot: Yeah, it's tricky. tevador: PoW might hit malicious nodes much harder than honest ones. Honest nodes: 12 outgoing connections. Malicious nodes: 1000 outgoing connections. articmine: We have to consider that the adversary is likely very vulnerable to out of network countermeasures such as public exposure and the risk of legal action boog900: spies use incoming connections for D boog900: I think putting PoW for incoming would be a DoS right? tevador: How do they get an incoming connection? By spamming the peer list. tevador: If entering the peer list requires a PoW, it will be harder to spam. boog900: They have a few nodes that make outgoing and spread the addresses of the many that just listen boog900: that would be a 1 time cost though? tevador: You can add a timestamp to the peer list and also hash the ID of the node keeping the list, so if they want to be included in 1000 peer lists, they need 1000x the PoW. boog900: presumably this adversary has quite a bit of resources, I don't think we can give them enough compute to discourage them without impacting normal nodes. tevador: My main point is that I would not dismiss PoW as a possible solution. articmine: I am not so sure. The adversary is also trying to hide. I am not the biggest fan of user POW but this may be an exception. articmine: POW is worth looking into as an option. Especially if we can reliably detect the spy nodes. articmine: There are interesting differences between honest and spy nodes that can be targeted libera.monerologs.net/monero…

CCS proposal: ProbeLab P2P Network Metrics Proposal. repo.getmonero.org/monero-pr…

ProbeLab CCS proposal for P2P network metrics (dashboard spy-node study) was discussed. CCS/GitLab was down due to disk-space issues, limiting access to the proposal text and prior comments. Main focus was licensing: ProbeLab proposed Polyform Noncommercial (source-available but explicitly not FOSS); community strongly preferred AGPLv3 (with optional non-commercial restrictions) for FOSS compatibility. Debate continued on the practical value of a new dashboard versus overlap with existing tools (e.g. rucknium/boog900’s dashboard at xmrnetscan.redteam.cash/) and a stronger preference for actionable research on Dandelion behavior in adversarial environments. Further discussion will continue in the CCS repository, the research lounge, and future meetings. rucknium: The CCS proposal website is temporarily down. I don't know when it may return. yiannisbot: Hmm.. bummer rucknium: yiannisbot gave comments last week after the meeting: libera.monerologs.net/monero… yiannisbot: Just as a reminder, we have proposed last week that we use an alternative license, which keeps things open source. Let me give a couple of links yiannisbot: We've seen the comments, yes, thanks for the feedback. yiannisbot: This is the license that we've proposed: polyformproject.org/licenses… - but of course, we're happy discuss, hear any concerns and negotiate. rucknium: Technically, Polyform is not open source. It is a type of source-available license I think: polyformproject.org/about yiannisbot: I see. So, IIUC, this is not acceptable, or seen favourably by the community? rucknium: Did you see kayabanerve's comment on it? libera.monerologs.net/monero… vtnerd: jeffro256 remove last slash rucknium: > Note: The proposed license above is not FOSS. That isn't to say I'm against its usage or reasoning for it, but I want to clarify that if there's a requirement for FOSS (e.g. by the CCS), that is insufficient unless an exception is granted (however that would happen). rucknium: > It wasn't claimed to be FOSS, I just want to be clear it doesn't check the "FOSS" box in case that matters as some people may not immediately understand that. articmine: yiannisbot This may well depend on the intended use case by members of the Monero community yiannisbot: What would be the preferred license? plowsof: not a good fit for the CCS no, you could try to debate the rule "All work must be licensed permissively at all stages of the proposal. There is no time where your work can be licensed under a restrictive license (even as you're working on it). Your proposal will be terminated if this is not remedied." but i doubt it would swing opinions enough to have your proposal merged rucknium: You said the reason you didn't like AGPL is because "On AGPL specifically: AGPL covers the code itself but leaves a gap for commercial use of the data that’s collected. PolyForm Noncommercial is a cleaner boundary for our situation, which we believe covers both sides." rucknium: AFAIK, usually CCS-funded code is MIT or GPL. articmine: The best model I see to allow the developer to sell proprietary software while maintaining FLOSS compatibility is the AGPL.v3.0 with customized permissions rucknium: I suggested AGPL because it specifically would require anyone running the code even if behind a server, like your competitors, to contribute back to the code. yiannisbot: Yeah, I understand the concerns. Would AGPL v3.0 be fine by the community? We would be ok to go with this in fact. articmine: For example one can restrict an AGPL permission to Non Commercial rucknium: yiannisbot: I think AGPL v3.0 would be OK with the community for the license. (There are other parts of your proposal that the community may disagree with, but the license should be ok.) rucknium: plowsof, Could you comment on using an AGPL license? yiannisbot: Should we decide that we go with AGPL v3.0 and discuss other parts? rucknium: Yes we can discuss other parts now. I don't see more discussion about license for now rucknium: IIRC, sgp_ said on the CCS website that he preferred ProbeLab working on the part network privacy issues instead of a dashboard. It's unfortunate that the CCS website is down. We cannot see the proposal and comments now, rucknium: And dennis_tra from ProbeLab added some comments in the CCS website. yiannisbot: I think Dennis's comments were mostly on the license part. But I can't remember exactly. rucknium: Sorry, it's hard to discuss the proposal with the website being down. I don't see more discussion on it during this meeting. We will come back to it once we can see the proposal again. yiannisbot: Yes, fair enough. So should the discussion continue in the repo, or in the next meeting? What's the suggestion? plowsof: originally, cuprate was AGPL (syntheticbird / boog900 can confirm the details) but the community was pushing for MIT - the compromise for CCS funded work was MIT licensing on binaries? jpk68: Pretty sure Cuprate is AGPL binaries and MIT libraries rucknium: plowsof: That wasn't a hard rule, was it? Just a community preference IIRC. sgp_: my main comment is that I don't think we really need a dashboard, I think we need research on how dandelion works in an adversarial environment, with the presence of a community ban list that X% of honest nodes use and is Y% effective at fingerprinting adversarial nodes plowsof: no not a hard rule moneromooo: rucknium: gitlab (and thus the ccs) is down due to lak of disk space, and will stay down until more disk is added. I've mentioned this in the core chat, no idea who reads it when though. rucknium: moneromooo: Thank you! boog900: plowsof: kinda: github.com/Cuprate/cuprate/i… boog900: the final binary is AGPL with the libs that can be used by others MIT boog900: most of our code is MIT rucknium: sgp_, Maybe this in "my doing". I suggested that ProbeLab start with monitoring to get trust and then after that to research the bigger questions. yiannisbot: sgp_ Agreed. We've been diving into Dandelion and want to do a study on this. But IMO, these are two separate things. The current CCS proposal is for a dashboard and a study on Spy nodes, which will ultimately pave the way for a Dandelion study sgp_: I personally see the dashboard as more of an ongoing cost than a benefit tbh sgp_: like, what would we use it for any why do we need it jpk68: Rucknium has already made a similar dashboard, right? rucknium: xmrnetscan.redteam.cash/ rucknium: The code I have runs much slower than what ProbeLab claims to have. My code (written with boog900) may start to hit the 24-hour daily scan limit. rucknium: My code is less robust and was missing data for a while. rucknium: And the ProbeLab monitoring includes monitoring on unreachable nodes, which mine does not. yiannisbot: The dashboard can be valuable for several things. Most importantly I would say if alerts are integrated. For instance, rapid change/shift of node geolocation could be a sign of an attack. articmine: It seems to me that this kind of dashboard would be useful for members of the community to spy and analyze the spy nodes. articmine: This will also help bring attention to this issue rucknium: We need to move to the final agenda item soon. It's the Grease proposal. yiannisbot: Fair enough, should we continue the discussion in the lounge, or the repo? Or next meeting? libera.monerologs.net/monero…

CCS proposal: ProbeLab P2P Network Metrics Proposal. repo.getmonero.org/monero-pr…

The MRL discussed the ProbeLab P2P Network Metrics CCS proposal. Rucknium shared new comments from ProbeLab and expressed difficulty recommending it due to the closed-source scanning code (despite acknowledged speed benefits over existing tools), significant overlap with boog900 and Rucknium’s open-source xmrnetscan.redteam.cash work, and preference for open-sourcing under AGPL or redirecting ProbeLab’s network analysis expertise toward solving the spy node problem instead. sgp_ and others agreed, favoring actionable research over another dashboard and questioning the need to continuously fund commercial offerings. rucknium: 7. CCS proposal: ProbeLab P2P Network Metrics Proposal (repo.getmonero.org/monero-pr…). rucknium: Got these new comments from ProbeLab: rucknium: repo.getmonero.org/monero-pr… rucknium: repo.getmonero.org/monero-pr… rucknium: I find it hard to recommend this CCS proposal, given the conditions offered at this time. I thought that the scanning code would be made open source, but it will remain closed source. rucknium: I am sorry to hear that another entity previously used your open source code without contributing back. But keeping code closed source because you are afraid of it being leveraged for commercial purposes is not the Monero way. Couldn't you release it under the AGPL license and avoid the problem? rucknium: Given the closed source code, I don't see enough benefit to the proposal. There is a lot of overlap between ProbeLab's monitoring and the code that boog900 and I already wrote for xmrnetscan.redteam.cash rucknium: IIRC, the ProbeLab code runs in just 11 minutes. Our code takes over 11 hours to run. I assume that ProbeLab didn't just use more hardware :D . So the speed is a benefit, especially as our runtime gets closer to 24 hours for the daily scan. rucknium: If these terms cannot change, I would be more interested in using ProbeLab's expertise in network analysis to actually solve the spy node problem. Monitoring is only one piece of the puzzle. rucknium: Here are some ideas presented by boog900 and myself: github.com/Rucknium/presenta… vimeo.com/1095371245 rucknium: Those are my comments. sgp_: I added one comment in the CCS that I prefer more of a research project to solve something actionable sgp_: imho we don't need a dashboard just to have one sgp_: plus we already have one plowsof: 1 on this feedback ofrnxmr: And be required to continuously fund a commercial offering. ofrnxmr: sounds backwards. Other commercial entities sponsor monero, not the other way around. Thats my 2.5c libera.monerologs.net/monero…