<yiannisbot:matrix.org> Hey @rucknium:monero.social I was wondering if you had any further thoughts from our chat last week (MRL) on our recent blogpost: probelab.io/blog/peering-into-priva…ve-into-the-monero-network-topology and if/how we can collaborate to dive deeper into the Monero network, get more insights and present in real-time dashboards at probelab.io.

<yiannisbot:matrix.org> Happy to jump in to another MRL if that's a better place to discuss - I just can't make it today :)

<rucknium> @yiannisbot:matrix.org: Yes I will follow up here right after the meeting.

<rucknium> @yiannisbot:matrix.org: There are at least three ways to get funding for Monero work. Keep in mind that Monero has no dev tax. All funding is based on donations from the community.

<rucknium> First, the Community Crowdfunding System (CCS). It is managed by the Monero Core Team. Most Monero work is funded through the CCS. Payout is done in XMR only. There is some exchange rate risk (on the downside and upside) if the purchasing power of XMR changes between when your proposal would go to funding and when the work is [... too long, see mrelay.p2pool.observer/e/kprF3fAKcXB6VGNa ]

<rucknium> Second, the MAGIC Monero Fund ( magicgrants.org/funds/monero ) is an arm of MAGIC Grants, a nonprofit incorporated under the 510(c)3) section of the U.S. federal tax code. Unlike the CCS, it can pay in fiat, i.e. USD, EUR, etc., or cryptocurrencies other than XMR. However, donations to MAGIC fundraising campaigns can [... too long, see mrelay.p2pool.observer/e/49LF3fAKVzM3QlR3 ]

<rucknium> Third is Kuno: kuno.anne.media . It is like a GoFundMe, but donations are raised in XMR. I wouldn't recommend Kuno for your project, but there is very little process/bureaucracy for getting approved for fundraising, unlike the CCS and MAGIC.

<rucknium> I think it's probably better to propose a small simple project and get it done. Then a larger, more complex project can come after you have built some trust and reputation.

<rucknium> (Starting small also makes it easier for me to recommend your project because there would be fewer unknowns.)

<rucknium> I forgot to say that at the CCS and MAGIC requires all your work to be licensed with an open source license.

<rucknium> I think you may want to proposed to set up continuous monitoring of the type that you did for the blog post, plus monitoring to estimate the number of unreachable nodes.

<rucknium> Estimating the number of unreachable nodes may be difficult, but I may be able to help with creating a maximum likelihood estimator or something. Here is a paper that tries to do it with Bitcoin. It cites a few papers that attempt their own estimates: Grundmann, Baumstark, & Hartenstein (2021) "Estimating the Peer Degree of Re [... too long, see mrelay.p2pool.observer/e/lvve3fAKT2p6NTdR ]

<rucknium> Monero is harder now because we have a portion of nodes performing subnet deduplication before connecting to outbound nodes.

<rucknium> Unreachable nodes are important because they are a little more vulnerable to IP-origin tracing of transactions than reachable nodes, due to how Dandelion++ works.

<rucknium> If I am a spy node and an unreachable node connected to me sends me a D++ stem-phase transaction, then I can infer that the true origin of the tx was probably that node. (There is an exception if the unreachable node has enabled inbound tx relay through Tor.)

<rucknium> A reachable node's stem-phase txs could come from that node or from any of its inbound connections. Stem phase txs are only relay toward an outbound connection.

<rucknium> But an unreachable node doesn't have that kind of plausible deniability because they have no inbound connections through which they could receive other nodes' stem-phase txs.

<rucknium> The D++ paper dismisses this problem in its discussion, but I and others think it's important. Probably there are a lot of Monero users who set up their own nodes through the Monero GUI wallet. Those users usually would have unreachable nodes because their computers, routers and/or ISPs would not unblock the inbound port by default.

<rucknium> There is an alternative protocol that doesn't have the D++ behavior, Clover, but I'm not sure that it's an overall improvement over D++: Franzoni, F., & Daza, V. (2022). Clover: An anonymous transaction relay protocol for the bitcoin P2P network. moneroresearch.info/222

<rucknium> Some potentially bigger projects for later:

<rucknium> * Try to make sense of the output of the packet analyzer from Kopyciok, Y., Schmid, S., & Victor, F. (2025). Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. moneroresearch.info/280 github.com/ykpyck/monero-traffic-analysis

<rucknium> I worked with it a little. I stopped when I didn't see a strong correlation between the anomalies that the packet analyzer was showing and the set of known spy nodes. Is there anything more in this paper that could help find true spy nodes?

<rucknium> * Do some work on resistance of the network to eclipse and partitioning attacks. You said in your recent blog post probelab.io/blog/probelabs-2025-review-and-2026-outlook

<rucknium> > Security Audits: One of the long-standing quests within our team has been that of the resilience of current P2P setups and networks, or in other words, what does it take for an adversary to cause disruption. In 2026, we plan to put our expertise in practice in this domain too. Without, of course, affecting the good operation [... too long, see mrelay.p2pool.observer/e/2qaU3vAKYVV4NVMy ]

<rucknium> There has been at least one attempted attack to shut down Monero nodes remotely: sethforprivacy.com/posts/moneros-ongoing-network-attack

<rucknium> MAGIC has funded a fuzzer to detect remote shutdowns against RPC before they become vulnerabilities: magicgrants.org/2025/11/17/Monero-RPC-Fuzzing and is seeking funding for one covering P2P: donate.magicgrants.org/monero/projects/fuzzing-monero-2

<rucknium> * Node versioning discovery could be helpful. The Monero's development practice is to hide node version for best privacy, but still there have been changes in how nodes respond to queries that could reveal some coarse versioning info. You would want to review version changelogs and discuss with Monero developers about some possibilities.

<rucknium> * A new Monero network simulator is almost finished: github.com/Fountain5405/monerosim . monerosim uses shadow, originally developed by the Tor Project. shadow runs the actual binaries of the nodes. Note: monerosim development was AI-assisted. You could try some experiments with monerosim . A 1000-node simulation has been run successfully.

<gingeropolous> ( almost.....)

<rucknium> Just waiting on the monerosim config files to work :)

<gingeropolous> i dunno if you wanna fiddle with it more, but you can just create a new config file using the smart config generator

<gingeropolous> i might have to push...

<gingeropolous> yeah all stuff is recently pushed. no more userspace ringdb wipe and no more monero path wipe

<rucknium> @gingeropolous:monero.social: Are you saying I should try the smart config generator instead of one of the example configs?

<gingeropolous> yeah if your up for it. I haven't had a chance to fiddle with the shipped configs recently, but I know that the smart config generator creates functioning configs, and the generate_config.y also creates functioning configs

<gingeropolous> generate_config.py . The smart generator uses an llm running on a glorious vega64 to create a scenario file, which is then expanded by the generate_config.py script

<gingeropolous> but generate_config.py can also be directly ran as a command line thing, and lordy the flags

<rucknium> A run with generate_config.py seems to have worked 😎

<gingeropolous> huzzah.

<gingeropolous> aw, you didn't try the smart config generator

<gingeropolous> it can take 5 mins on the vega64 :(

<gingeropolous> was there enough flags for yah on that one?

<rucknium> I just did python scripts/generate_config.py --agents 30 --duration 8h -o my_config.yaml

<rucknium> @gingeropolous: I did before I realized it was AI. I did it locally and got ModuleNotFoundError: No module named 'yaml'