15:11:02 MRL meeting in this room in two hours. 17:00:28 Meeting time! https://github.com/monero-project/meta/issues/1474 17:00:32 1. Greetings 17:00:41 hello there 17:00:48 h 17:00:50 Hello 17:00:53 Hello 17:01:00 hi 17:01:05 waves 17:01:40 Hi 17:02:36 2. Updates. What is everyone working on? 17:03:52 me: Opened a PR to defeat the Nyx eclipse attack: https://github.com/monero-project/monero/pull/11527 . Now looking at whether the patch would defeat the Moros attack against newborn nodes. 17:03:59 me: currently working on updating all my open prs, and blocked on a new fix while I determine the best course of action 17:04:05 Howdy 17:04:06 hi. working on monerosim. stuck on SoP ambiguities in spec for selfish mining mitigations. Some sim optimization wins. discovered cycling monerods really slows down sim. 17:04:11 als some minor updates to lws 17:04:16 Me: random work on various PRs, hoping to have I2P SAM merged soon 17:04:23 mostly been working on wallet and daemon fixes/reviews in core 17:04:52 me: addressing PR review backlog on my PRs, and doing review 17:05:14 @rucknium: Me: working out a bunch of changes to our selection and eviction logic (that doesnt require bump to 45k nodes) as an alternative or follow up to ruck's pr. probably relstes to the above 17:05:25 me: some stressnet monitoring, finalizing the logic to take an unlock time by timestamp and determine an output's last locked block in prep for the Phase 2&3 audit just so code is in a more settled state before RFQ goes out, PR review 17:06:11 Hi 17:06:58 @gingeropolous:monero.social: tevador is here. You can pose Share or Perish spec questions to them. 17:08:20 yay! basically, how are displaced blocks re-judged? 17:08:58 Is this an agenda item? 17:09:37 No. It could be put in Any Other Business, at the end. 17:10:06 Can we also discuss Anthropic's oss-scanner at the end, if there's time? 17:10:17 https://github.com/anthropics/oss-scanner/ 17:10:28 @jpk68:matrix.org: Yes. 17:10:47 3. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). FCMP++ Integration Audit Overview (https://github.com/seraphis-migration/monero/issues/294). Network upgrade [... too long, see https://mrelay.p2pool.observer/e/2OuRp7QLTjd6QjZD ] 17:12:42 On upstream FCMP++ integration PR's: Responded to all LLM review comments, those are ready for re-review. Currently working on finalizing logic to get last locked block from custom unlock_time, then will request @sgp_:monero.social send out the RFQ's for Phases 2 & 3 audits 17:13:00 mx25519 continues to be a bottleneck to HF activation. Although, thankfully, tevador re-licensed mx25519 here: https://github.com/tevador/mx25519/pull/53/, and the mx25519 merge PR https://github.com/monero-project/monero/pull/10964 has been updated for that. I'm hoping that this compromise is acceptable to all parties, and we can move forward with the carrot_core merge eventually. 17:13:37 Multisig still in progress 17:14:34 On Research audits: the circuit + gadgets round 2 audit with Least Authority is underway 17:15:14 I will review PoWER within the next ~month 17:15:22 FWIW, I have approved Monero PR 10964. I think it only needs approval from tobtoht. 17:17:01 https://github.com/monero-project/monero/pull/10915 and https://github.com/monero-project/monero/pull/10916 are PRs which both fix existing issues in the daemon, and help with the transition to FCMP++. I am re-working 10915 now, should be done by EOD. 17:19:53 Anything more on this topic? 17:20:25 nothing from me 17:20:59 nothing from me 17:21:00 4. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). 17:22:09 nothing major to report on my end on beta stressnet, seems to be going smooth. need to review logs to see how the latest round of tx relay v2 changes is holding up, and if all looks good, that should be ready for mainnet 17:23:02 Yeah to be fair, not a lot of stressing so far, but the network seems to be functioning well 17:23:43 sech1 had a solid period of stressing and I have logs from that period 17:24:29 If we weren't running big simulations on the 1TB RAM machine, I would be spamming txs. 17:26:31 5. 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 (https://github.com/monero-project/monero/pull/11527). 17:27:14 I made this PR: https://github.com/monero-project/monero/pull/11527 . There are some details and possible additions I want to discuss. 17:28:00 But first I want to give anyone the opportunity to respond to it as-is. 17:30:55 1. In the PR I don't increase the gray_list size. Maybe it would make sense to do that. Increasing the gray_list isn't a way to defend against the Nyx attack, but maybe it's a good idea to increase it to defend against other attacks. 17:31:58 My changes bucket both lists 17:32:03 It's hard to prevent an adversary from filling the gray_list with its own peers. They are not (initially) checked for connectivity by the node. And the node allows multiple ports on the same IP address., 17:32:17 max sizes 4096 white and 8192 gray 17:32:52 256 buckets of 16 and 32 17:33:06 I thought maybe the node could hold only one port per IP address in the gray_list, but that would allow an adversary to bump an honest node out of the list by feeding false ports for an honest IP address. 17:33:49 I think blindly increasing sizes has diminishing returns under peerlists that are not static and all online 17:35:07 It seems obvious that a node with a wide view of the network would be harder to eclipse than a node with a narrow view of the network. 17:35:21 Lists fill will dead nodes amd are never evicted 17:35:23 Sometimes things that seem obvious are not actually true. 17:36:00 but if this were ipv6 mode, couldn’t the attacker just spam with valid ips and still eventually replace the valid peers? 17:36:08 Its not a biew of the network is 40k/45k are dead 17:36:30 If* the 17:36:31 @ofrnxmr: That's one of the additions that I think could help. I assumed that the white_list had a housekeeping behavior and evict-on-no-response behavior like the gray list does, but it doesn't. Probably some housekeeping for the white-list should be added. 17:37:13 @rucknium: No, its blindly evicting oldest over limit 17:37:27 @rucknium: I added 17:37:39 I don't see how IPv6 will be safe until something like proof-of-storage, with all its downsides, is deployed. 17:38:20 I mean widespread use of IPv6, maybe as the default. 17:39:03 An simple-ish partial solution I've been thinking about is to, for each peer list entry, keep track of the node which told you about this entry (originator). When the limit is hit, instead of erasing based on insert time, erase the entry with the closest originator 17:39:13 I think it could even make sense to do white_list housekeeping whenever a new peer is added to the white_list. Why? To prevent this augmentation of the Nyx attack: 17:39:25 @jeffro256: Part of bucketing additons added 17:39:57 Is there a PR somewhere? 17:40:07 No, still wip 17:40:26 An adversary can temporarily control an IP address with open ports by using a commercial VPN that permits port opening. Then, the adversary could put a lot of peers into the white_list that would respond to a temporary ping-pong. So the adversary does not even need permanent control of all the adversary IP addresses. 17:40:47 A bunch of changes stacked on too of each other, want to test combined and separate before concluding x is better than y 17:41:05 Looks like we may enter a quite prolonged phase of experimentation and competing approaches until things finally settle ... 17:41:10 @rucknium: Also changed that they cant inject into white 17:41:13 @jeffro256: But what if an adversary controls 1,000 IP addresses, like in the Nyx attack paper? 17:41:31 @rucknium: According to plowsof's obaervatory, they control over 2500 17:41:42 @rucknium: Sorting originators by ASN may help in this case. The originator order function could be anything, really 17:41:51 rbrunner: I want to avoid that because this is a vulnerability that the network has no defense against yet. 17:42:13 Sounds reasonable 17:42:15 60% of reachable nodes are implicated in being sus 17:42:39 Which is one of the reasons why I went for minimal changes. 17:43:38 semi relae 17:43:55 interesting way to spell release 17:44:14 semi-related to the discussion: https://github.com/Boog900/monero-ban-list/issues/18 17:44:27 Hello fellas 17:44:38 AFAICT, Ruck's change are almost strictly better in most cases that I can think of (except perhaps maybe speed). I need to check the time signature of the output selection algo again. Because an effectively ~1950x bigger list might have >1950x impact on speed, depending on time signature 17:44:49 jeffro the problem is if everyone would use ASN - and the adversary defeats it, its possible that we would be worse off. 9/10 ai research papers agree that its great fix if me, you and a handful of others use it but not the whole network 17:44:52 To update we will need to coordinate signatures again ... 17:45:11 @boog900: it wasn't that bad 17:45:17 I was just late of one month 17:45:35 said ai research https://github.com/plowsof/crawler-research/blob/main/Monero-Peer-AS-Deduplication/pdf/monero-peer-asn-deduplication.pdf 17:45:39 @jeffro256:monero.social: Did you see my reason for picking the specific white_list size limit? I am not committed to that value, but at least it has a non-arbitrary reason for it, instead of the reason being humans having 10 fingers. 17:45:57 no but they will just switch IPs again I don't really want to keep this cat and mouse going forever 17:46:14 @jeffro256: yes 17:46:45 I would be OK with lowering alpha. Or some other reasonable value. 17:47:17 The code can afford to be really inefficient when operating on a list of size 20 17:47:22 The third complementary change (the first two were gray_list size and whte_list housekeeping) would be caching the peerlist that peers send to each other. It would: 17:47:57 1. Prevent the CPU load of re-shuffling the white_list every time a (potential adversary) peer requests it 17:48:27 2. Prevent white_list "enumeration" but an adversary, where the adversary can get the whole contents of the white_list by just requesting it many times. 17:48:42 "enumeration" by* 17:49:47 By the way, some of these additional suggestions come from the LLM review of my PR ( https://github.com/xmrack/monero-review/issues/1088 ) and the Shi et al. research team. 17:51:32 I mean, the LLM review told me that the white_list doesn't have housekeeping, which I should have realized before. 17:52:51 Where do we go from here? 17:53:16 @ofrnxmr:monero.social: You or I could run the Nyx simulation with your patch once you finish it. 17:55:01 @jeffro256:monero.social: AFAIK, the code was already, in theory, processing the whole gray_list in that section of code, which can get up to 5000 records. It just limited the white_list to 20. 17:56:09 @boog900: @ofrnxmr:monero.social: I think there has to be a good fingerprint with negligible risk of false positives if the ban list is to be updated. 17:57:33 Oops. Meant to ping @boog900:monero.social in that message. 17:57:57 Discussion can continue in the PR and on Matrix/IRC 17:58:06 More on this topic for now? 17:59:17 Caching and algo improvement, I guess. I need some more time to think about it. > <@rucknium> Where do we go from here? 17:59:59 Sounds good > <@rucknium> @ofrnxmr:monero.social: You or I could run the Nyx simulation with your patch once you finish it. 18:00:29 (but its ~8 patches fwiw) 18:01:11 I need to fix these monerosim config files by the way. Accidentally got the ones for the 26 hour run instead of the 50 hour run: https://github.com/Rucknium/misc-research/tree/main/Monero-Eclipse-Attack/nyx/code/monerosim-config 18:02:45 6. Any other business. 18:03:23 We had @gingeropolous:monero.social 's question for tevador about the Share or Perish spec 18:03:44 There's also the Anthropic thing 18:03:51 Yes 18:04:34 the long version (warning, ai gen): https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/mrl146_briefing.md 18:05:58 For Q1, the intention was that the weight becomes objective once the fork point is 48 work objects deep. 18:05:59 shorter versions: n_f is ambiguous: the formal definition counts only the alt chain's work objects, but the prose says the lateness factors apply when "the two chains differ by fewer than k*w," and those give different answers, so 18:05:59 we need to know which one is intended. 18:06:15 @gingeropolous:monero.social: I requested and received SoP simulation code from these researchers: https://github.com/monero-project/research-lab/issues/146#issuecomment-5978803129 18:07:25 I don't quite get the LLM phrasing of Q2. 18:07:56 yeah my heads been having trouble getting around it. maybe this: displaced blocks: the spec doesn't say what to do with blocks a reorg knocks off, and since n_f and lateness depend on which branch you're on, the same two branches can both say SWITCH, so the rule can flip back and forth. 18:08:35 also made this visual: https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/fork_choice_loop.html 18:09:32 yah gotta download it cause github pages are beyond me for some reason 18:09:33 I don't think that can happen. 18:10:07 hrm, perhaps if i solidify Q1 in the implementation then Q2 will go away. 18:10:14 I don't think it can cycle. The weight doesn't change when you switch chains. 18:10:46 If either chain is 48 work objects from the fork point, the objective weight kicks in. 18:13:25 ok, awesome. thank you! i think the remaining stuff is just fiddly 18:13:35 Btw, my python simulation code is not authoritative. It can have bugs. 18:14:20 the remaining points are peer bans: SoP lets nodes switch to a branch with fewer blocks, and stock monerod penalizes peers whose height drops and never forgives it, so honest nodes end up banning each other for 24h unless the p2p scoring changes too. 18:14:52 and forking: putting the workshare count in version_minor breaks things because v0.18 uses that field as the hard fork vote, so most SoP blocks get rejected by nodes that haven't upgraded as "old version." 18:15:39 I'm not sure what the rationale is for banning peers whose height drops. Cumulative difficulty can also cause a reorg to a shorter chain. 18:17:24 I'm not familiar with any "hard fork vote" rule. I thought version_minor was only indicative and not used for anything consensus-related. 18:17:49 yeah i was surprised by that as well 18:18:20 Can anyone confirm that nodes reject blocks based on version_minor? 18:18:43 i thought it was seen in the sim run, but i'll double check 18:18:49 https://monero-book.cuprate.org/consensus_rules/hardforks.html 18:19:14 > The block's vote must be greater than or equal to the version, a vote higher than the maximum known hard-fork is interpreted as a vote for the latest hard-fork3. So if a block is at V2 then the vote must be V2 or higher 18:20:02 vote = minor but there is an edge case for minor = 0 where vote = 1 18:20:27 why make it simple 18:20:46 "must" => block rejected if violated? 18:21:14 If we really have this rule than SoP cannot be used without a hard fork removing this rule. 18:21:15 yes: https://github.com/monero-project/monero/blob/eac1b86bb2818ac552457380c9dd421fb8935e5b/src/cryptonote_basic/hardfork.cpp#L109 18:21:59 Does anyone oppose removing this useless consensus rule? 18:22:32 I think the whole vote system can go 18:23:52 Looks like moneromooo coded this part 18:23:55 IIRC some code relies on there being no HF where the activation is not at the height set in the table which would break if a HF gets delayed due to votes. 18:23:56 im launching some sims to confirm 18:25:52 I can put this hard fork rule, and maybe the vote system, on next meeting's agenda. 18:26:09 @jpk68:matrix.org: Can you explain Anthropic's oss-scanner? 18:27:39 @boog900: https://github.com/monero-project/monero/pull/9404#discussion_r1710484050 18:32:20 @rucknium: Sure. It's a program similar to oss-fuzz, where project maintainers can submit a request to have it scanned by LLMs automatically. Any findings are sent to the listed emails in the project.yaml file. 18:33:03 Several notable projects have already been merged, including Bitcoin Core, Botan, libtorrent, and OpenSSL 18:34:40 Considering that quite a few issues have already been found using LLMs, and this would allow us to presumably get feedback from unreleased frontier LLMs, it seems like a good opportunity, IMO 18:35:27 Though it's worth noting that a "project maintainer" has to submit the application. Either a member of the Core Team or tobtoht, I guess 18:37:30 Seems ok to me. 18:37:48 bF said he was ok with doing it 18:39:01 I'll just explicit the obvious here. There is a marketing incentive for Anthropic to use these open source projects into increasing their count of vulnerabilities found with their models. Anthropic has been advocating for closed and regulated access of AI models. Whether we care about helping participating to this end or being pragmatic about it as a project is something to think about. 18:39:30 saying this because I only heard the KYC argument so far 18:40:04 I suppose you could similarly question Google's intentions with oss-fuzz. We have also not yet established whether KYC is required for this Claude thing 18:40:08 @syntheticbird:monero.social: Then Monero games its number by classifying all findings as low severity :D 18:40:27 IIRC bF offered to do the KYC part 18:40:41 @syntheticbird: it's a wrong argument afaik 18:41:07 @thomasbuilds:matrix.org: I meant discussion 18:41:09 I slopped a draft commit for adding Monero to the repo: 18:41:09 https://github.com/jpk68/oss-scanner/commit/88898203c5e9db395ceb4c13495abfd310f6a487 18:41:09 my bad 18:41:31 @rucknium: That would actually be very funny to pull 18:42:22 > <@syntheticbird> I'll just explicit the obvious here. There is a marketing incentive for Anthropic to use these open source projects into increasing their count of vulnerabilities found with their models. Anthropic has been advocating for closed and regulated access of AI models. Whether we care about helping participati [... too long, see https://mrelay.p2pool.observer/e/7Z3hqbQLZE0zM044 ] 18:42:22 Lets not pretend that m$ isnt already doing this on github 18:42:23 the only downside I see is that anthropic finds a big vuln and would not disclose it and report it to gov agencies or whetever. 18:42:46 @thomasbuilds:matrix.org: I am afraid of this 18:42:53 @thomasbuilds:matrix.org: They could just do this anyways 18:42:55 @ofrnxmr: GitHub do not make use pay more or regulate us more because we are an open source project. 18:42:56 They play dirty 18:42:57 wrong analogy imo 18:42:57 but then they wouldn't wait that we enroll, why would they? 18:42:58 @ofrnxmr: This is also a response to thomas 18:42:59 True 18:43:13 @syntheticbird: Anthropic scanner is free afaik? 18:43:59 I don't see why Monero would be singled out here, either, in that case 18:44:10 For example SimpleX is enrolled as well 18:45:25 yeah also if we trust google there's no reason to not trust anthropic? 18:45:53

I think the threat model file in the submission needs some more work @jpk68:matrix.org 18:46:21 Good point, yes 18:47:13 @ack-j:matrix.org: you certainly have some experience on this matter ;) 18:47:41 <321bob321> @ofrnxmr: Until they start charging when they get market share 18:47:52 @ofrnxmr: If anthropic advocacy wins it will be much harder for everyone to download and use AI models and potentially help monero in their own terms 18:48:39 This is my point in that Github is not against us. While Anthropic uses us and will eventually go against our interest in the long-term. 18:48:47 @syntheticbird: Us enrolling is entirely unrelated to whether Anthropic will succeed in a regulatory sence, and even if it was, how does not enrolling prevent them from still scanning Monero's code and using the findings for malicious purposes? 18:48:53 Supposing they do win their argument ofc 18:49:14 i can't imagine they win. cats outta the bag 18:49:46 @jpk68:matrix.org: yes to first part. and second part unrelated. Never claimed they would be doing so and I would be surprised if they do so 18:49:50 Doing this would only make sense if you're trying to "send a message" about what we (some of us) think about Anthropic, and I don't think governments hold much weight to the perspectives of The Monero Project :P 18:49:54 and our decision to take advantage of this aint gonna change what they do 18:49:57 @syntheticbird: maybe but we should profit from it before imo, there's so much more to get rn 18:49:57 <321bob321> You assume that they will tell you there is an issue 18:50:12 Again, irrelevant 18:50:20 They're probably scanning it already 18:50:38 ah in that sense 18:50:43 well we don't know that 18:50:46 I'll end the meeting here. Discussion can continue. 18:50:55 thx everyone 18:51:28 I won't continue the discussion I was just poking the thing and people can decide by themselves and vote. I think the ramification are clear and people are minded enough to have their take on it 18:51:29 @syntheticbird: If they want to find bugs in the code, they'll scan it anyways, and our enrollment doesn't matter in the slightest 18:52:02 @jpk68:matrix.org: the point was about publicly supporting Anthropic entity that way. 18:52:13 of course nothing prevents Anthropic from doing what they want 18:52:20 ^ > <@jpk68:matrix.org> Doing this would only make sense if you're trying to "send a message" about what we (some of us) think about Anthropic, and I don't think governments hold much weight to the perspectives of The Monero Project :P 18:52:21