rucknium presented simulation results for the Nyx eclipse attack under different patches and adversary strategies (separate /24s vs. 10 nodes per /24). His patch and ofrnxmr’s proposed changes perform roughly the same in the reviewed scenarios; ofrnxmr’s aims to handle more diverse strategies and includes bucketing, coarser deduplication, test-before-evict, and one outbound peer per netgroup. Images of results were shared. interestingband argued that any P2P without node weights is doomed, that whitelist changes are pointless, and that the correct approach is weighting nodes by hashrate/mining capability (non-miners connect via miners). Several participants pushed back: most nodes do not mine, a small miner could give an adversary an advantage, IPv4 scarcity currently provides a form of address limitation, and the proposed patch is a simple, practical defense against the specific Nyx cookbook attack rather than a comprehensive sybil solution. vtnerd supported the PR for that reason while noting residual issues without IPv4 scarcity. ofrnxmr described the concrete changes in the proposed series and noted they are not mutually exclusive with rucknium’s PR. rucknium listed possible paths (merge his PR, ofrnxmr’s, both, do nothing, or another solution). Discussion continued on list-size trade-offs, academic vs. practical approaches, and the need for a stop-gap while larger designs are explored.
rucknium: 7. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260). p2p: increase white_list size and change connection selection algorithm (
rucknium: ofrnxmr: Do you want to discuss your proposed patches?
interestingband: p2p without any weight for nodes is doomed to fail by design, since all nodes are equal
interestingband: No idea why you are wasting time on white list change, it's pointless
plowsof:
rucknium: interestingband: It fixes this specific attack. It's not pointless.
interestingband: There is an approach for p2p layer around nodes based on their weight which should be linked to their mining capabilites, all other nodes should be connected via them. Done.
interestingband: It doesn't fix any attack
interestingband: It's the same pointless approach as OSPEAD for decoy selection
rucknium: The simulation proves it fixes the Nyx attack.
interestingband: Your simulation is far from reality then, bcs monero should work with any anonymous network
jeffro256: Solution to problems with decentralized network: make it centralized. Nice. > interestingband: There is an approach for p2p layer around nodes based on their weight which should be linked to their mining capabilites, all other nodes should be connected via them. Done.
ofrnxmr: Not the same thing, but the 101s drop replacement i spoke about at last meeting (not implemented) would add some metric of weighting to whether peeer connections are dropped (instead of random selection). My series does test-before-evict as well
vtnerd: The change makes the attack harder, but as interestingband: points out its difficult to determine which nodes to select and why. The node weight isn't anymore centralized than the mining process
boog900: most nodes do not mine and a lot of miners don't run nodes
vtnerd: Otoh, most nodes arent mining so Im not sure how that would work
vtnerd: Yes
boog900: Chainalysis would just need to run a small miner to get an advantage over normal nodes
gingeropolous: i've tasked the bots with a similar thing, current progress here: 
boog900: Or insert adversary
plowsof: is mining hash cheaper than renting ips? who knows
vtnerd: chainanalysis just needs to convince everyone to switch to ipv6 and it's the same issue
rucknium: My patch definitely isn't meant to solve all network sybil issues. It's just a simple, quick patch to prevent major network disruption if an adversary decides to use the Nyx cookbook soon.
vtnerd: Yes, I support the pr for that reason. Just pointing out that it's dicey without ipv4 scarcity
ofrnxmr: rucknium do you want to share the prelim results of the recent sims?
rucknium: Yes. Do you want to explain what you patches do?
syntheticbird: vtnerd: on the topic of expensive addressing and communication protocol against sybil attacks. monero p2p over meshtastic would be a blast for common people and a bummer for adversaries.
rucknium: your*
rucknium: meshtastic bandwidth is likely too little.
syntheticbird: true
boog900: Yeah our current network security relies on addresses being limited, I don't think PoW is the answer though
syntheticbird: sadness then
interestingband: jeffro256: You don't get it; it's about being clear about who is partiicpant and who is not, and assumptions of the decentralized "game". And centralized way is what you all are doing by relying on ipv4 subnet.
rucknium: Recently, 10% of Tor exit nodes were acting maliciously. Then the Tor project just removed them from the directory. Monero can't do that.
ofrnxmr: * Bucket whitelist into into 256 buckets of 16 > rucknium: Yes. Do you want to explain what you patches do?
ofrnxmr: * bucket graylist into 256 buckets of 32
ofrnxmr: * dedup by /16 instead of /24
ofrnxmr: * test peers before evicting from whitelist
ofrnxmr: * one outbound peer per netgroup (IPv4 /16, IPv6 /32)[... more lines follow, see https://mrelay.p2pool.observer/e/nMCU6rgLd3BQR2l4 ]
rucknium: 
(outbound-adversaries-unreachable-status-quo-rucknium-ofrnxmr.png)
rucknium: ^ Here the Nyx attack eclipse results. The first two you've seen before. The bottom one is ofrnxmr 's patch.
interestingband: I didn't specify anywhere any assumption about underlaying network cleanet, tor, i2p. The approach with explicit weight linked to hashrate works with any network.
rucknium: It's stochastic, so just one run with one unreachable node doesn't show the large-sample average.
ofrnxmr: rucknium: This is if the attacker has each node in a separate /24
rucknium: Yes
ofrnxmr: Results look different if we concentrate the nodes, and likely different still if the ratio of goodto bad is less in our favor
rucknium: Now, when the attacker has 10 nodes in each /24. (Well, not "each" /24. But 10 per /24. Same number of adversary nodes total (1000) )
rucknium: 
(outbound-adversaries-unreachable-status-quo-rucknium-ofrnxmr-10per.png)
rucknium: In this scenario, even the unpatched node does OK after a while because it has rbrunner7 's subnet deduplication logic.
interestingband: jeffro256: And alternative p2p layer can be active in parallel with what is active atm, with explicit share of resources between them. This way you get benefits of both at the cost of 1/N resource per each channel of communication. LOL
rucknium: I'd say with the scenarios we have reviewed, my patch and ofrnxmr 's patch perform roughly the same. But ofrnxmr 's patch intends to handle more diverse adversary strategies, AFAIK.
interestingband: What are the assumptions of your model for simulation, and what is proven in your simulation ? or it's just statistics for different strategies ?
rucknium: It is reassuring that an adversary really needs to have IP addresses in separate subnets to perform the attack. Thanks to gingeropolous for helping patch a bug in monerosim to allow us to test the 10per-subnet scenario.
rucknium: interestingband: I explain that in the PR description: 
rucknium: I assume that the adversary is carrying out the Shi et al. (2026) Nyx eclipse attack. There are other possible attacks, of course, that I don't model in the simulation.
interestingband: "TL;DR: An adversary with 1,000 or more IP addresses under its control ..." this part is solved with p2p based on weight linked to hashrate
interestingband: and then miners has weight, non miners has to rely on some miners or be a miner
interestingband: done
interestingband: whole PR can be wiped
gingeropolous: for a well-funded adversary hashrate isn't as expensive as we'd want it to be. trust me im a believer in PoW solves all the things but ....
rucknium: I solve it in fewer lines.
interestingband: Nah, it's the only mechanism to protect network and consensus: contribute to hashrate
interestingband: or rely on someone who does
boog900: > or rely on someone
interestingband: it's pointless to have p2p network disconnected from consensus
rucknium: Possible paths I see are: 1) My PR is reviewed and merged. 2) ofrnxmr make a PR and gets it reviewed and merged. 3) combination of both. 4) Do nothing. 5) Some other solution is developed.
interestingband: 5
sgp_: There are clearly downsides to prioritize by hashrate lol. But if you really want to propose this idea then write it up instead of interrupting
interestingband: and all prev options are not an option at all since they are analysed in the context of all monero components
ofrnxmr: rucknium: Ours arent mutually exclusive, mine can easily revert some of the changes from yours if mine is to be accepted later
interestingband: sgp_: I will
ofrnxmr: its much more lines than yours, of course, since it solves multiole issues that can arguably land on their own
interestingband: sgp_: And I'm not just interrupting, I've already said how to implement it so that both ways can coexist at the same time in backward compatible way
rucknium: vtnerd: I welcome you to review my PR on GitHub:
ofrnxmr: I mean, monero doesnt typically like when you do 20 things in a single pr, so i might just start upstreaming certain commits that fix actual bugs, or fix bad behavior
rucknium: Anything else on this item for now?
interestingband: rucknium: What are the downsides of bigger lists ? Why not have it bigger or smaller ?
interestingband: "The defense scenario simulation increased the white_list size limit from 1,000 to 10,000. The limit was set arbitrarily. To be effective, the value in the simulation just needed to exceed the total count of the sum of honest and adversary nodes." So that constant is just a number to "fix" one attack scenario in your simulation, without validation of all other use cases or even proving anything at all ?
rucknium: Bigger list would mean slower performance in routines that operate on the list.
interestingband: Basically blind bit flip
interestingband: How many hours has been wasted on that ? LOL
rucknium: This research team that has written multiple papers about eclipsing the Monero network has suggested increasing the white_list size for over a year.
rucknium: Simpler fixes are better than complex fixes, ceteris paribus.
ofrnxmr: Mine increases the size because its not reasonable to bucket peers with a small 1000 whitelist
interestingband: rucknium: Those ppl successfully wasted time in a spirit of academic research with their useless formalism. That's the most important part of academic research that should not be adopted by MRL.
ofrnxmr: white = 256 * 16 = 4096, gray he 256 * 32 = 8192. Iirc bitcoin is 256 * 64 = 16384
ofrnxmr: Mine ^
rucknium: This attack is very practical and not just hypothetical (formal) at all.
rucknium: I'll end the meeting here. We can continue discussing after.
interestingband: Yes, but your approach to solve it is wrong and solution is bad
rucknium: Thanks everyone.
interestingband: The same as OSPEAD, real attack / problem, but solution is bad
boog900: interestingband: rucknium: picked this up after multiple reports about how weak our address book is, in the latest paper they did a real attack on our seed nodes. The solution stops their attack. Yes it does not go all the way to make our address book and p2p layer completely secure but it could certainly be a stop gap while you work on a whole extra P2P layer.
boog900: Thanks rucknium 🙏
syntheticbird: Thanks Rucknium
interestingband: boog900: My commetns mostly about goal and analysis of the solutions for the stated problems (problems are kinda known already). Bcs most solutions I don't like personally can be rejected by anyone else who is doing proper indenpendent/unbiased analysis of them.
sgp_: interestingband: just propose PoS or whatever with nodes with stake getting connection preference
syntheticbird: nah spirobel already have the PoS proposer role
interestingband: I was talking about aligning p2p with PoW consensus, do you see a difference ?
sgp_: no I don't pls explain. PoS = PoW
sgp_: we can't have 2 people championing similar ideas or else it might make progress
interestingband: sgp_: Please make sure that you are not touching any code with this depth of understanding of reality.
boog900: Its easy to say it would be better to do XYZ, but until XYZ is done all we have is Ruck's PR.
sgp_: yeah ruck's is a trivial fix with clear immediate benefits. it's not meant to be a comprehensive solution
jpk68: lmfao
syntheticbird: jpk68: ssssshhhhhhhhhhhhhh
jpk68: sgp_: ^
jpk68: That's what I meant to reply to, oops
syntheticbird: Don't say oops. Impose your mistakes.
gingeropolous: interestingband: if you wanna read the great stat machines output from your entropy:
syntheticbird: inb4 your sim sucks because you didn't specify things correctly and its all your fault
syntheticbird: also I have a working prototype that is much better
gingeropolous: its not even a sim at this point, just arithmetic.
syntheticbird: gingeropolous: don't underestimate one's blindness in front of a proof
interestingband: boog900: Btw, I think approach with independent ref implementation is a nice way forward, but it can be done faster I think than how it's going with cuprate atm.
spirobel: reductive > syntheticbird: nah spirobel already have the PoS proposer role
gingeropolous: although i do like what the bot came up with as an alternative sorta based on it: "5a. Inbound connections beyond a per-/16 quota pay a workshare per handshake"
syntheticbird: spirobel: how so? You are very into proposing PoS. Does that remove any of your other accomplishment?
syntheticbird: no
interestingband: syntheticbird: top-bottom analysis doesn't require looking into simulation numbers, since my comment was about simulation model setup and it's assumptions.
spirobel: syntheticbird: we talked extensively about this. People can just read the comments i made back then and left on the PoS CCS
syntheticbird: well ok sorry for the joke
boog900: interestingband: Nice 👍️
syntheticbird: interestingband: how?
interestingband: sgp_: Atm There are 2 approaches for the best consensus, and it's either PoW (but it requires diff logic around RandomX) or something called proof-of-pledge based on physical devices with real pledge inside, so it's not a ephemeral PoS with nothing at stake, but it's a stake per participant, and it looks like it can't be implemented in reality due to some fundamental reasons.
boog900: syntheticbird: Just yolo slop it all
interestingband: syntheticbird: How ? 1. stop writing prose about code, and write code, 2. ...
syntheticbird: interestingband: That's my bad. I was expecting some constructive from your mouth but ig I set the bar too high.
boog900: You know a lot about writing code and not talking right?
interestingband: syntheticbird: Nah, i've just commented about your blog post about code, it's a waste of time
syntheticbird: interestingband: just imagine if I gave a fuck
syntheticbird: about your opinion
syntheticbird: imagine
sgp_: ooh this pledge thing sounds fun, is it like the pledge of allegiance to monero. nodes need to prove they are true people who have sworn allegiance, and aren't a bad guy. so kinda like a permissioned network cult, but cool
interestingband: LOL
gingeropolous: instead of getting hostile i recommend the ignore feature of this glorious technology
syntheticbird: sgp_: putting symbolism on the protocol like that would be hilarious
sgp_: ok i'll stop sorry. put up or shut up with a written, organized, well-reasoned proposal
sgp_: until then I don't care about comments about some mythical PoW node selection basis
interestingband: sgp_: Nah, it's about real resource backing digital token, any real resource locked in a box
gingeropolous: im tellin yah, there might be something in the botslop: " Inbound connections beyond a per-/16 quota pay a workshare per handshake"
interestingband: sgp_: In the context of MRL, there is a need for a formal proof for cryptography, but atm it's just audits with "opninions", so is your advice applicable to your own efforst or no ?
interestingband: Anyway, I'm talking about research relevant for monero, it doesn't contradict with the purpose of MRL
sgp_: uh, no
sgp_:
sgp_: see "The Latest Development: zkSecurity's Formal Verification"
interestingband: I can't submit CCS proposal due to downtime, and any work upfront isn't eligible for funding, so that's why it's private atm > sgp_: ok i'll stop sorry. put up or shut up with a written, organized, well-reasoned proposal
sgp_: and also see "What Formal Verification Doesn't Tell Us"
interestingband: sgp_: That one is nice, I even reacted to your comment about it back then. But it's not enough, and it's just 1 audit
interestingband: sgp_: My entry is effect in reality, I never chase goals that are disconnected from reality. I guess my formal verification is a bit different from what is done by others.
syntheticbird: interestingband: You can there is a pastebin for it
interestingband: operations CCS means all types of participants can interact with each other, offline archive / queue of proposals isn't operational CCS
interestingband: syntheticbird: I hope you are not touching any critical code with this depth of understanding of reality.
syntheticbird: ^ > interestingband: Please make sure that you are not touching any code with this depth of understanding of reality.
syntheticbird: sense of humor or genuinely low IQ ?
interestingband: I've never reviewed any code written by you, but I just don't know any human who can solve complex problems with code and like to write prose about code at the same time.
syntheticbird: I need to frame this message on my wall
syntheticbird: this is peak comedy
interestingband: 
https://github.com/Cuprate/cuprate/pull/6, 2 PRs where you add relatively big change and then wipe it later, so it doesn't look like I'm wrong, LOL
interestingband: I don't argue about your ability to write prose, you are probably good at it
rucknium: This conversation can be moved to #monero-research-lounge:monero.social
thomasbuilds: yeah u guys need to move from the lab and go sit on the long chairs
ofrnxmr: Ok, we dont needthe echo
thomasbuilds: arguing in the lab can break a sample and boom next corona virus comes out
interestingband: rucknium: ok, I have nothing more to add on that topic atm
View quoted note →
GitHub
Build software better, together
GitHub is where people build software. More than 225 million people use GitHub to discover, fork, and contribute to over 800 million projects.
Monero P2P Observatory
GitHub
monerosim/README.md at progress-brief · Fountain5405/monerosim
monero network simulation tool. Contribute to Fountain5405/monerosim development by creating an account on GitHub.
(outbound-adversaries-unreachable-status-quo-rucknium-ofrnxmr.png)
rucknium: ^ Here the Nyx attack eclipse results. The first two you've seen before. The bottom one is ofrnxmr 's patch.
interestingband: I didn't specify anywhere any assumption about underlaying network cleanet, tor, i2p. The approach with explicit weight linked to hashrate works with any network.
rucknium: It's stochastic, so just one run with one unreachable node doesn't show the large-sample average.
ofrnxmr: rucknium: This is if the attacker has each node in a separate /24
rucknium: Yes
ofrnxmr: Results look different if we concentrate the nodes, and likely different still if the ratio of goodto bad is less in our favor
rucknium: Now, when the attacker has 10 nodes in each /24. (Well, not "each" /24. But 10 per /24. Same number of adversary nodes total (1000) )
rucknium: (outbound-adversaries-unreachable-status-quo-rucknium-ofrnxmr-10per.png)
rucknium: In this scenario, even the unpatched node does OK after a while because it has rbrunner7 's subnet deduplication logic.
interestingband: jeffro256: And alternative p2p layer can be active in parallel with what is active atm, with explicit share of resources between them. This way you get benefits of both at the cost of 1/N resource per each channel of communication. LOL
rucknium: I'd say with the scenarios we have reviewed, my patch and ofrnxmr 's patch perform roughly the same. But ofrnxmr 's patch intends to handle more diverse adversary strategies, AFAIK.
interestingband: What are the assumptions of your model for simulation, and what is proven in your simulation ? or it's just statistics for different strategies ?
rucknium: It is reassuring that an adversary really needs to have IP addresses in separate subnets to perform the attack. Thanks to gingeropolous for helping patch a bug in monerosim to allow us to test the 10per-subnet scenario.
rucknium: interestingband: I explain that in the PR description: GitHub
p2p: increase white_list size and change connection selection algorithm by Rucknium · Pull Request #11527 · monero-project/monero
TL;DR: An adversary with 1,000 or more IP addresses under its control can pack its IP addresses into honest nodes' peer lists and successfully ...
GitHub
p2p: increase white_list size and change connection selection algorithm by Rucknium · Pull Request #11527 · monero-project/monero
TL;DR: An adversary with 1,000 or more IP addresses under its control can pack its IP addresses into honest nodes' peer lists and successfully ...
GitHub
monerosim/README.md at hashrate-gating · Fountain5405/monerosim
monero network simulation tool. Contribute to Fountain5405/monerosim development by creating an account on GitHub.
The Road to Divisors in Monero
MAGIC Grants | Charity for scholarships, public cryptocurrency infrastructure, and educational materials
GitHub
Removing `old_database/` by SyntheticBird45 · Pull Request #100 · Cuprate/cuprate
Painful but necessary. Let's all give a moment of silence for my diligent and yet incomplete database :P
#monero-research-lab