Performance impact of growing white_list to ~45k peers appears acceptable (especially with cached peerlists). ofrnxmr’s complementary/competing work is blocked by the 101s peer drop (which preferentially drops good peers and selects likely attackers); white-first selection is a workaround, full fix would restore gray-list usability. Debate on whether the drop is effective against eclipse vs. other attacks (spying, txpool manipulation). rucknium’s monerosim runs (Nyx + Moros) show the patch reduces Moros effectiveness so far; longer status-quo runs planned. ofrnxmr’s local-model results on the 101s version look promising; binaries available for monerosim comparison. thomasbuilds offered re-review if needed. rucknium: Last time, jeffro256 asked about the potential performance impacts if the white_list grew to 45,000 peers, due to my PR:

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 ...

rucknium: thomasbuilds asked his LLM bot to write some performance tests. I ran them myself and wrote this in #monero-research-lounge:

#monero-research-lounge

You're invited to talk on Matrix

You're invited to talk on Matrix

rucknium: The performance impact seemed OK to me, especially if the shared peerlists in handshakes and time_sync requests is cached instead of reshuffled on every request. rucknium: AFAIK ofrnxmr was working on a complementary and/or competing PR ofrnxmr: Yeah, my main roadblock (annoyance) is the 101s peer drop ofrnxmr: With it, we have to do white-first peer selection. So i have a series that uses white-first simple because i didnt want to dig into fixing the 101s blind drop. But a complete fix would change that, and allow using gray list again gingeropolous: iirc , that was put in to attempt some mitigation against being eclipsed or something. ofrnxmr: Well it doesnt work rucknium: Why is the 101 second peer drop a problem? ofrnxmr: It drops a good peer and selects a likely attacker every 101s rucknium: That's assuming you have good peers to start with. gingeropolous: ^^^ thomasbuilds: > rucknium thomasbuilds asked his LLM bot to write some performance tests. I ran them myself and wrote this in #monero-research-lounge:

#monero-research-lounge

You're invited to talk on Matrix

You're invited to talk on Matrix

thomasbuilds: I'm not very involved in this PR (lots of other work todo!). However if u would need a re-review at some point don't hesitate to ask. ofrnxmr: an eclipse assumes you arent being sent blocks (among other things), good peers send blocks rucknium: thomasbuilds: Thank you. rucknium: ofrnxmr: Not necessarily. ofrnxmr: Dropping 101s means that we track who sends us good blocks, when they last sent, etc rucknium: The objective of an adversary might not require it to withhold blocks. ofrnxmr: for an eclipse? rucknium: It could be pure spying or just manipulate the txpool ofrnxmr: Yeah, but thats a differnet attack. Im any case, the change doesnt keep all 12 connections, but it stop dropping good ones ofrnxmr: Currently, at startup, we select 8/12 peers from the white list, then the other 4 from gray. Then drop 1/12 every 101s and select another from gray (iirc) rucknium: Not a different attack according to the definition in Franzoni & Daza (2022) rucknium: And it's difficult to know if blocks are being withheld, in the short term. That's why you sometimes get that warning in the monerod console about having too few blocks over a period of time, due to randomness of block production rates. ofrnxmr: in any case, the series can likely be tested now, with 101s and white-first, but id prefer to change the 101s logic in what id consider to be a complete fix ofrnxmr: (i have run local models on it, that showed very promising results) ofrnxmr: (On the version that has the 101s drop) rucknium: By local models do you mean monerosim? ofrnxmr: no, the data is generated w/o running a node ofrnxmr: If you want to run it through monerosim as-is, i can share the current state later today rucknium: I can run it through monerosim or you can. Up to you. ofrnxmr: Ehh, i dont know how to use monerosim and not really interested in figuring it out 😅 ofrnxmr: It would be your test though - same params etc that you ran yours under, just with my binaries rucknium: I'll do it. No problem. ofrnxmr: Appreciate it rucknium: ofrnxmr: No. I am going to cheat :D rucknium: (This is a joke) ofrnxmr: Even if cheating, i think the results should be promising rucknium: I tried to see if my patch would defeat the Moros attack, a related attack in the Shi et al. paper that attacks newborn nodes by poisoning seed nodes' white_lists. I set the simulation to attack with the worst case scenario: Nyx attack against all honest nodes and Moros attack (I implemented it as the same as Nyx, just against the seed nodes) against seed nodes. Then start an unreachable node a few hours after the attack begins. rucknium: The 50-hour sim didn't reach equilibrium fast enough. I had enough time to do a 100-hour sim just for the proposed defense and a 50-hour sim for the status quo. I will try to do the 100 hours for the status quo soon. rucknium: (outbound-adversaries-unreachable-moros.png) rucknium: (white-list-unreachable-moros.png) rucknium: Here are the results. So far, it looks like the patch reduces the effectiveness of the Moros attack. rucknium: That's all from me on this item.

#monero-research-lab

View quoted note →