<rucknium> MRL meeting in this room in two hours.

<rucknium> Meeting time! monero-project/meta #1474

<rucknium> 1. Greetings

<syntheticbird> hello there

<ap4sh:matrix.org> h

<jpk68:matrix.org> Hello

Hello

<vtnerd> hi

<jberman> waves

<articmine> Hi

<rucknium> 2. Updates. What is everyone working on?

<rucknium> me: Opened a PR to defeat the Nyx eclipse attack: monero-project/monero #11527 . Now looking at whether the patch would defeat the Moros attack against newborn nodes.

<vtnerd> me: currently working on updating all my open prs, and blocked on a new fix while I determine the best course of action

<jeffro256> Howdy

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

<vtnerd> als some minor updates to lws

<jpk68:matrix.org> Me: random work on various PRs, hoping to have I2P SAM merged soon

<ap4sh:matrix.org> mostly been working on wallet and daemon fixes/reviews in core

<jeffro256> me: addressing PR review backlog on my PRs, and doing review

<ofrnxmr> @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

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

Hi

<rucknium> @gingeropolous:monero.social: tevador is here. You can pose Share or Perish spec questions to them.

<gingeropolous> yay! basically, how are displaced blocks re-judged?

Is this an agenda item?

<rucknium> No. It could be put in Any Other Business, at the end.

<jpk68:matrix.org> Can we also discuss Anthropic's oss-scanner at the end, if there's time?

<jpk68:matrix.org> github.com/anthropics/oss-scanner

<rucknium> @jpk68:matrix.org: Yes.

<rucknium> 3. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed). FCMP++ Integration Audit Overview (seraphis-migration/monero #294). Network upgrade [... too long, see mrelay.p2pool.observer/e/2OuRp7QLTjd6QjZD ]

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

<jeffro256> mx25519 continues to be a bottleneck to HF activation. Although, thankfully, tevador re-licensed mx25519 here: tevador/mx25519 #53, and the mx25519 merge PR monero-project/monero #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.

<jberman> Multisig still in progress

<jberman> On Research audits: the circuit + gadgets round 2 audit with Least Authority is underway

<jberman> I will review PoWER within the next ~month

FWIW, I have approved Monero PR 10964. I think it only needs approval from tobtoht.

<jeffro256> monero-project/monero #10915 and monero-project/monero #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.

<rucknium> Anything more on this topic?

<jberman> nothing from me

<jeffro256> nothing from me

<rucknium> 4. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

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

<jeffro256> Yeah to be fair, not a lot of stressing so far, but the network seems to be functioning well

<jberman> sech1 had a solid period of stressing and I have logs from that period

<rucknium> If we weren't running big simulations on the 1TB RAM machine, I would be spamming txs.

<rucknium> 5. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (arxiv.org/pdf/2609.10260). p2p: increase white_list size and change connection selection algorithm (monero-project/monero #11527).

<rucknium> I made this PR: monero-project/monero #11527 . There are some details and possible additions I want to discuss.

<rucknium> But first I want to give anyone the opportunity to respond to it as-is.

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

<ofrnxmr> My changes bucket both lists

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

<ofrnxmr> max sizes 4096 white and 8192 gray

<ofrnxmr> 256 buckets of 16 and 32

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

<ofrnxmr> I think blindly increasing sizes has diminishing returns under peerlists that are not static and all online

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

<ofrnxmr> Lists fill will dead nodes amd are never evicted

<rucknium> Sometimes things that seem obvious are not actually true.

<vtnerd> but if this were ipv6 mode, couldn’t the attacker just spam with valid ips and still eventually replace the valid peers?

<ofrnxmr> Its not a biew of the network is 40k/45k are dead

<ofrnxmr> If* the

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

<ofrnxmr> @rucknium: No, its blindly evicting oldest over limit

<ofrnxmr> @rucknium: I added

<rucknium> I don't see how IPv6 will be safe until something like proof-of-storage, with all its downsides, is deployed.

<rucknium> I mean widespread use of IPv6, maybe as the default.

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

<rucknium> 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:

<ofrnxmr> @jeffro256: Part of bucketing additons added

<jeffro256> Is there a PR somewhere?

<ofrnxmr> No, still wip

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

<ofrnxmr> A bunch of changes stacked on too of each other, want to test combined and separate before concluding x is better than y

Looks like we may enter a quite prolonged phase of experimentation and competing approaches until things finally settle ...

<ofrnxmr> @rucknium: Also changed that they cant inject into white

<rucknium> @jeffro256: But what if an adversary controls 1,000 IP addresses, like in the Nyx attack paper?

<ofrnxmr> @rucknium: According to plowsof's obaervatory, they control over 2500

<jeffro256> @rucknium: Sorting originators by ASN may help in this case. The originator order function could be anything, really

<rucknium> rbrunner: I want to avoid that because this is a vulnerability that the network has no defense against yet.

Sounds reasonable

60% of reachable nodes are implicated in being sus

<rucknium> Which is one of the reasons why I went for minimal changes.

<boog900> semi relae

<syntheticbird> interesting way to spell release

<boog900> semi-related to the discussion: Boog900/monero-ban-list #18

<slowbeardigger:matrix.org> Hello fellas

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

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

<boog900> To update we will need to coordinate signatures again ...

<syntheticbird> @boog900: it wasn't that bad

<syntheticbird> I was just late of one month

said ai research github.com/plowsof/crawler-research…f/monero-peer-asn-deduplication.pdf

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

<boog900> no but they will just switch IPs again I don't really want to keep this cat and mouse going forever

<ofrnxmr> @jeffro256: yes

<rucknium> I would be OK with lowering alpha. Or some other reasonable value.

<jeffro256> The code can afford to be really inefficient when operating on a list of size 20

<rucknium> 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:

<rucknium> 1. Prevent the CPU load of re-shuffling the white_list every time a (potential adversary) peer requests it

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

<rucknium> "enumeration" by*

<rucknium> By the way, some of these additional suggestions come from the LLM review of my PR ( xmrack/monero-review #1088 ) and the Shi et al. research team.

<rucknium> I mean, the LLM review told me that the white_list doesn't have housekeeping, which I should have realized before.

<rucknium> Where do we go from here?

<rucknium> @ofrnxmr:monero.social: You or I could run the Nyx simulation with your patch once you finish it.

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

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

<rucknium> Oops. Meant to ping @boog900:monero.social in that message.

<rucknium> Discussion can continue in the PR and on Matrix/IRC

<rucknium> More on this topic for now?

<jeffro256> Caching and algo improvement, I guess. I need some more time to think about it. > <@rucknium> Where do we go from here?

<ofrnxmr> Sounds good > <@rucknium> @ofrnxmr:monero.social: You or I could run the Nyx simulation with your patch once you finish it.

<ofrnxmr> (but its ~8 patches fwiw)

<rucknium> 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: github.com/Rucknium/misc-research/t…se-Attack/nyx/code/monerosim-config

<rucknium> 6. Any other business.

<rucknium> We had @gingeropolous:monero.social 's question for tevador about the Share or Perish spec

<jpk68:matrix.org> There's also the Anthropic thing

<rucknium> Yes

<gingeropolous> the long version (warning, ai gen): github.com/Fountain5405/monerosim/b…/docs/assets/sop/mrl146_briefing.md

For Q1, the intention was that the weight becomes objective once the fork point is 48 work objects deep.

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

<gingeropolous> we need to know which one is intended.

<rucknium> @gingeropolous:monero.social: I requested and received SoP simulation code from these researchers: monero-project/research-lab #146#issuecomment-5978803129

I don't quite get the LLM phrasing of Q2.

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

<gingeropolous> also made this visual: github.com/Fountain5405/monerosim/b…cs/assets/sop/fork_choice_loop.html

<gingeropolous> yah gotta download it cause github pages are beyond me for some reason

I don't think that can happen.

<gingeropolous> hrm, perhaps if i solidify Q1 in the implementation then Q2 will go away.

I don't think it can cycle. The weight doesn't change when you switch chains.

If either chain is 48 work objects from the fork point, the objective weight kicks in.

<gingeropolous> ok, awesome. thank you! i think the remaining stuff is just fiddly

Btw, my python simulation code is not authoritative. It can have bugs.

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

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

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.

I'm not familiar with any "hard fork vote" rule. I thought version_minor was only indicative and not used for anything consensus-related.

<gingeropolous> yeah i was surprised by that as well

Can anyone confirm that nodes reject blocks based on version_minor?

<gingeropolous> i thought it was seen in the sim run, but i'll double check

<boog900> monero-book.cuprate.org/consensus_rules/hardforks.html

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

<boog900> vote = minor but there is an edge case for minor = 0 where vote = 1

<syntheticbird> why make it simple

"must" => block rejected if violated?

If we really have this rule than SoP cannot be used without a hard fork removing this rule.

<boog900> yes: github.com/monero-project/monero/bl…/cryptonote_basic/hardfork.cpp#L109

Does anyone oppose removing this useless consensus rule?

<boog900> I think the whole vote system can go

<rucknium> Looks like moneromooo coded this part

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

<gingeropolous> im launching some sims to confirm

<rucknium> I can put this hard fork rule, and maybe the vote system, on next meeting's agenda.

<rucknium> @jpk68:matrix.org: Can you explain Anthropic's oss-scanner?

<boog900> @boog900: monero-project/monero #9404#discussion_r1710484050

<jpk68:matrix.org> @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.

<jpk68:matrix.org> Several notable projects have already been merged, including Bitcoin Core, Botan, libtorrent, and OpenSSL

<jpk68:matrix.org> 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

<jpk68:matrix.org> 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

<rucknium> Seems ok to me.

<ofrnxmr> bF said he was ok with doing it

<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 participating to this end or being pragmatic about it as a project is something to think about.

<syntheticbird> saying this because I only heard the KYC argument so far

<jpk68:matrix.org> 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

<rucknium> @syntheticbird:monero.social: Then Monero games its number by classifying all findings as low severity :D

IIRC bF offered to do the KYC part

<thomasbuilds:matrix.org> @syntheticbird: it's a wrong argument afaik

<syntheticbird> @thomasbuilds:matrix.org: I meant discussion

<jpk68:matrix.org> I slopped a draft commit for adding Monero to the repo:

<jpk68:matrix.org> jpk68/oss-scanner 8889820

<syntheticbird> my bad

<syntheticbird> @rucknium: That would actually be very funny to pull

<ofrnxmr> > <@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 mrelay.p2pool.observer/e/7Z3hqbQLZE0zM044 ]

<ofrnxmr> Lets not pretend that m$ isnt already doing this on github

<thomasbuilds:matrix.org> 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.

<slowbeardigger:matrix.org> @thomasbuilds:matrix.org: I am afraid of this

<jpk68:matrix.org> @thomasbuilds:matrix.org: They could just do this anyways

<syntheticbird> @ofrnxmr: GitHub do not make use pay more or regulate us more because we are an open source project.

<slowbeardigger:matrix.org> They play dirty

<syntheticbird> wrong analogy imo

<thomasbuilds:matrix.org> but then they wouldn't wait that we enroll, why would they?

<ofrnxmr> @ofrnxmr: This is also a response to thomas

<slowbeardigger:matrix.org> True

<ofrnxmr> @syntheticbird: Anthropic scanner is free afaik?

<jpk68:matrix.org> I don't see why Monero would be singled out here, either, in that case

<jpk68:matrix.org> For example SimpleX is enrolled as well

<thomasbuilds:matrix.org> yeah also if we trust google there's no reason to not trust anthropic?

<ack-j:matrix.org> I think the threat model file in the submission needs some more work @jpk68:matrix.org

<jpk68:matrix.org> Good point, yes

<thomasbuilds:matrix.org> @ack-j:matrix.org: you certainly have some experience on this matter ;)

<321bob321> @ofrnxmr: Until they start charging when they get market share

<syntheticbird> @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

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

<jpk68:matrix.org> @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?

<syntheticbird> Supposing they do win their argument ofc

<gingeropolous> i can't imagine they win. cats outta the bag

<syntheticbird> @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

<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

<gingeropolous> and our decision to take advantage of this aint gonna change what they do

<thomasbuilds:matrix.org> @syntheticbird: maybe but we should profit from it before imo, there's so much more to get rn

<321bob321> You assume that they will tell you there is an issue

<jpk68:matrix.org> Again, irrelevant

<jpk68:matrix.org> They're probably scanning it already

<syntheticbird> ah in that sense

<syntheticbird> well we don't know that

<rucknium> I'll end the meeting here. Discussion can continue.

<syntheticbird> thx everyone

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

<jpk68:matrix.org> @syntheticbird: If they want to find bugs in the code, they'll scan it anyways, and our enrollment doesn't matter in the slightest

<syntheticbird> @jpk68:matrix.org: the point was about publicly supporting Anthropic entity that way.

<syntheticbird> of course nothing prevents Anthropic from doing what they want

<jpk68:matrix.org> ^ > <@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

<syntheticbird> but enrolling in gives a form of acceptance

<syntheticbird> thats all

<syntheticbird> @jpk68:matrix.org: Monero project only cares about the monero community, your last part is silly

<jpk68:matrix.org> I don't think you read my message right. I'm talking about what Anthropic and co. think of Monero, not the other way around

<syntheticbird> Yes

<syntheticbird> and im saying that I don't care about this and this isn't the point

<syntheticbird> The point is that the Monero project has some accountability to its community in enrolling into a program that benefits a company that are advocating against the common user interest.

<syntheticbird> Which boils down to "is it far fetched enough that we don't care."

<jpk68:matrix.org> You haven't given one single example of how this benefits Anthropic, besides using it for publicity, and I think almost everyone would agree that not reporting severe security issues in exchange for less purported publicity is not a good deal

<syntheticbird> idk you are being all defensive all of the sudden

<syntheticbird> will it reassure you to know that I am for enrolling ?

<thomasbuilds:matrix.org> it doesn't benefit anthropic lol, the point here is blending in and extracting the obvious value.

<syntheticbird> There is no example to be given because this is a speculation.

<syntheticbird> Anthropic advocacy is a fact, the usage that they will do of this program is my mind probably for this

<syntheticbird> thus reporting it for discussion.

<syntheticbird> But against this is speculation. You wanna shovel that away for keeping your precious claude access, feel free to do so.

<jpk68:matrix.org> Well yeah, I'm defending opposition to a clearly misconstrued argument, no offense > <@syntheticbird> idk you are being all defensive all of the sudden

<syntheticbird> again*

<syntheticbird> @jpk68:matrix.org: bro you are being ridiculous

<syntheticbird> why do you act like im being malicious

<syntheticbird> what is miconstructed here?

<jpk68:matrix.org> "Misconstrued" does not imply that you're being malicious?

<syntheticbird> thats your defensive behavior that I consider as you finding me malicious

<syntheticbird> but ig im wrong

<jpk68:matrix.org> In this case, it looks like we are good to proceed :D > <@syntheticbird> will it reassure you to know that I am for enrolling ?

<syntheticbird> you are not the only one in the channel

<thomasbuilds:matrix.org> anyone against actually?

<syntheticbird> (online or offline)

<syntheticbird> @thomasbuilds:matrix.org: this is to avoid this kind of ridiculous proceeding that monero have a minimal week long PR review policy

<syntheticbird> I think you can understand why

<syntheticbird> This is to ask during next meeting when most people will be there or when people will have share their votes beforehand if not available

<syntheticbird> half of the chat fleed at rucknium saying "thx"

<jpk68:matrix.org> IDK, maybe you scared them off ;)

<slowbeardigger:matrix.org> lol

<syntheticbird> @slowbeardigger:matrix.org: am i that ugly ?

<slowbeardigger:matrix.org> youre handsome

<slowbeardigger:matrix.org> marry me birb

<slowbeardigger:matrix.org> Anthropic already has studied monero code e2e, doesnt matter if we enroll

<slowbeardigger:matrix.org> we should do what's best for monero community, thats it

<slowbeardigger:matrix.org> if we enroll we enroll

<slowbeardigger:matrix.org> The only losing part is the part that doesnt use em :p

<thomasbuilds:matrix.org> the whole difficulty is getting enrolled btw

<slowbeardigger:matrix.org> I know KYC is a bitch no one likes it

<thomasbuilds:matrix.org> why is this kyc argument getting brought up again aaaaa

<thomasbuilds:matrix.org> I told you there's no kyc

<jpk68:matrix.org> For the umpteenth, time we don't know if there's KYC

<slowbeardigger:matrix.org> ah, no kyc, sorry sorry

<slowbeardigger:matrix.org> what are the requirements?

<slowbeardigger:matrix.org> let me look em up

<thomasbuilds:matrix.org> none, be important enough basically

<slowbeardigger:matrix.org> Monero is big af

<jpk68:matrix.org> If anyone would like to sell their soul for some free tokens, here are some links:

<jpk68:matrix.org> openai.com/form/codex-for-oss

<jpk68:matrix.org> claude.com/contact-sales/claude-for-oss

<jpk68:matrix.org> Good luck!

<ofrnxmr> @slowbeardigger:matrix.org: wrong room, but not the first time ive heard some of those words

<slowbeardigger:matrix.org> Monero or big af?

<slowbeardigger:matrix.org> jk jk

<syntheticbird> > <@slowbeardigger:matrix.org> we should do what's best for monero community, thats it

<syntheticbird> my reasoning is that monero is first and foremost a technical project, not enrolling for this reason would be perceived as a political position. I also think Monero will be virtually a drop in the ocean of vulnerability used by Anthropic for its advocacy, meaning we aren't that much of an incidence. That's why I'm still for en [... too long, see mrelay.p2pool.observer/e/lt3OqrQLWXoydXV6 ]

<slowbeardigger:matrix.org> @syntheticbird: i see

<syntheticbird> So I'm bringing this up so that next meeting the most weighted contributors can decide over this duality fully aware.

<jpk68:matrix.org> "Most weighted" as in "big af"?

<ofrnxmr> i view it as: free "audits". Monero is bsd, so "free = you are the product" doesnt help us at all

<ofrnxmr> as in, there is no "opt-out"

<syntheticbird> @jpk68:matrix.org: one way to spell it 👍️

<slowbeardigger:matrix.org> big af baby

<jpk68:matrix.org> Just like your mom

<thomasbuilds:matrix.org> u mom so big when she sits in front of the sun she creates an eclipse

<321bob321> 1. Either you don't enrol and they scan you any way

<321bob321> 2. You enrol and you give them public permission to scan you and hope they provide you with results, unless another entity with lots money says tell me.first

<slowbeardigger:matrix.org> @jpk68:matrix.org: mama im a criminal criminaaaal

<thomasbuilds:matrix.org> @thomasbuilds:matrix.org: middle school jokes lol

<slowbeardigger:matrix.org> @thomasbuilds:matrix.org: Sppeaking of eclipse attack, any other ideas regarding the spy nodes?

<gingeropolous> PoWER

( jeffro256: 10964 LGTM now, waiting for CI to complete )

<gingeropolous> i guess thats not direct though, as it currently stands

<syntheticbird> @321bob321: 1. is a speculation which I think is unlikely because of their incentives strategy. Anthropic so far have never historically reported vulnerabilities about projects that weren't partnered with them. They are also not vuln hunters, they are an AI companies showing their cybersecurity capabilities to the world, s [... too long, see mrelay.p2pool.observer/e/ov3tqrQLcEtnekQw ]

<syntheticbird> So if Anthropic always used vulnerabilities for marketing, always found within partners and finally cannot even exploit the found ones, my most straightforward conclusion is that they do not scan non-partnered project on a daily basis

<gingeropolous> gotta find a way to keep p2p connections cheap enough for a user, but costly enough so its actually annoying to spin up 2k fake p2p connections

<ofrnxmr> Its not about vuln gatekeeping, but about using our code to train their LLMs on, which theyve all been doing

<syntheticbird> @ofrnxmr: i mean Dan's argument was vuln gatekeeping, but yes yours is right

<ofrnxmr> I mean, w/o asking them to tell us abt the vulns, theyll just be training data on vulns, which is probably how aloppers are able to find exploits with csrefully crafted prompts

<ofrnxmr> Its likely that these LLMs already are aware of the vulns, but dont tell anyone because they arent programmed to. They just put them in a locker called "downgrade if user asks abt this"

<slowbeardigger:matrix.org> @gingeropolous: mmmm

<ofrnxmr> @gingeropolous: Ginger knows its pretty chesp to spin up fake python nodes :P

<gingeropolous> yah! it works in monerosim...

<ofrnxmr> The fix there is, imo, bucketing, asmap, proper eviction, proper rotation, etc

<syntheticbird> nah

<slowbeardigger:matrix.org> was thinking OHTTP but is not cheap to implement, and wont solve anything, just a extra step

<syntheticbird> the fix is monero core drm

<syntheticbird> with cpu trusted execution engines

<gingeropolous> lol

<ofrnxmr> An adversary needs to spend a lot of $ on distributed IPs to obtain a fraction of the connections

<gingeropolous> IPs are cheap for these companies though. but the VPS they are probably getting the IP from is prolly 1 vCPU with 256mb ram

<ofrnxmr> Not if they are in distinct asns and limited ips per subnet

<ofrnxmr> Its cheap to buy 1000 ips in the same subnet, not cheap to buy 1000 ips in a different subnet per ip

<ofrnxmr> Which is why DO has like 1200 ips taking up 40% of our white list. Its cheap

<gingeropolous> i thought we had the ip bucketing stuff already

<ofrnxmr> @gingeropolous: Nope

<ofrnxmr> Only deduplication of peer selections, not injecting directly into our white lists

<ofrnxmr> And its /24 iirc

<ofrnxmr> And if it doesnt find good peers, it happily uses the same subnet on the next pass

<rucknium> I think the Digital Oceans ones are not all in the same subnets.

<ofrnxmr> @rucknium: No, but they are the same asn :P

<rucknium> Yeah

<ofrnxmr> there are also hundreds of nordvpn ones

<ofrnxmr> And a iirc like 1000 that restart at the same time every day

<gingeropolous> what did rbrunners thing do?

<ofrnxmr> Deduplicated connections (iirc)

<ofrnxmr> but if an attacker controls the peerlists, it doesnt work

<rucknium> @gingeropolous:monero.social: Deduplicate subnets from the white_list, but does not change the actual contents of the white_list. Same for gray_list.

<ofrnxmr> It will eventuslly eclipse itself and select peers from the same subnets

<rucknium> I mean, deduplciate at the point in time when you select a new outbound connection

<ofrnxmr> Yeah, also doesnt apply to inbound iirc

<gingeropolous> ah ok so we never did the bitcoin asn aware whitelist thing

<ofrnxmr> Right

<ofrnxmr> Bitcoin has optional asmap. It uses subnet and address bucketing by default

<gingeropolous> whats our hesitation on adopting bitcoins solution?

<ofrnxmr> Thats what i did

<slowbeardigger:matrix.org> mmm what if an advertised address would remain a candidate, before that endpoint could enter a protected peer set or gain a selection weight, the receiving node would require a fresh proof of work form the endpoint being admitted not from the honest peer that happened to advertise it

<slowbeardigger:matrix.org> like:

<slowbeardigger:matrix.org> a receiver generated a unpredictable nonce, the candidate endpoint and the exact proposed admission, a short expiry and protocol version, and a receiver selected work target within fixed limits.[... more lines follow, see mrelay.p2pool.observer/e/4dqnq7QLLXMzLUJV ]

<rucknium> My perspective: @boog900:monero.social has said for over a year that it would be good to harden Monero's address book. But it hasn't been a priority. Now there is this released vulnerability that should be patched. More complicated solutions take longer to review. I also personally feel some responsibility for the vulnerabilit [... too long, see mrelay.p2pool.observer/e/oM-sq7QLdFVoeXA2 ]

<rucknium> I couldn't reproduce their results. And they didn't really respond to follow-up questions. So I thought maybe it wasn't a real vulnerability. When they published this full paper, I changed my mind.

<syntheticbird> Rucknium is feeling sad, Someone must be sacrificed for the contributors people's good

<slowbeardigger:matrix.org> @syntheticbird: needs to be a virgin to be sacrificed?

<rucknium> Don't forget this is the MRL room

<syntheticbird> I'm responsible for corrupting the young visitors and members and will take the ban.

<syntheticbird> (sorry i'm shutting it up)

<boog900> @slowbeardigger:matrix.org: There are many ways to do PoW but you need to show that this can prevent spy nodes while allowing normal nodes still

<boog900> I think a PoW based solution on its own is impossible

<slowbeardigger:matrix.org> @boog900: yeah no, was thinking of it but that may end up affecting honest nodes.

<rucknium> My reachable node is sort of doing your node a favor when it allows your node to initiate a connection to me. Add a lot of CPU overhead to that? I will kick you off.

<slowbeardigger:matrix.org> sowy

<boog900> the difference between low end node hardware and the amount of time the PoW can take vs a machine dedicated to PoW is too big.

<rucknium> I don't mean to shut down discussion of connection PoW.

<rucknium> Or Monero could just keep its inefficient tx relay protocol. That's one way to make connections expensive :D

<rucknium> The proof of storage paper is probably the better move, but it has downsides.

<slowbeardigger:matrix.org> @rucknium: never heard of it

<slowbeardigger:matrix.org> cons and pros? if you dont mind

<rucknium> ieeexplore.ieee.org/document/10174897

<syntheticbird> @rucknium: I believe these are the types of ideas that deserves a multiple year endeavor type of experiments

<slowbeardigger:matrix.org> ty

<boog900> This is the best thing I could come up with and it isn't the most practical thing: monero-project/research-lab #160

<rucknium> You have to "encrypt" the blockchain. And I don't know how it would affect node pseudonymity. For example, if I change my node's IP address, do I have to re-do the encryption for a new "identity"?

<boog900> yes

<slowbeardigger:matrix.org> interesting interesting

<rucknium> There's this MRL issue about it: monero-project/research-lab #126

<slowbeardigger:matrix.org> thanks, checkin'

<rucknium> @rucknium: I was wrong. This issue shows that Boog first suggested hardening the address book two years ago, not one year ago.