<rbrunner7> Will try. Sadly my old brain forgot many of the details of that list management already however ...

<gingeropolous> dunno if i'll make the meeting today. Some updates - i started implementing features into monerosim that require modifications to monerod. 1st was a way to test hardforks, this was done weeks ago. 2nd is using actual PoW in the simulation so we can test all the fun selfish mining countermeasures. i think that one is mostly don [... too long, see mrelay.p2pool.observer/e/gfXVm6sLWThLcG9P ]

<sgp_> mrelay.p2pool.observer/m/monero.social/aARReNmOfcqmogJOgeuGHTyg.png (image.png)

<sgp_> For the meeting later today, here is the anonymized table of quotes that we received for the FCMP++ circuits audit

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

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

<rucknium> 1. Greetings

<jpk68:matrix.org> Hello

<sgp_> Hello

<articmine> Hi

Hello

<dnvie:matrix.org> Hi

<jberman> waves

<vtnerd> Hi

<jeffro256> Howdy

<boog900> Hi

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

<rucknium> me: Selfish mining defenses. Reading the new Monero research papers and trying to reproduce their results.

<vtnerd> me: still on ssl fixing the —proxy issue. realized our existing p2p connection routines block an ASIO::run call via synchronous code such that you need at least 2 ASIO threads for the p2p server to work. so figuring out whether I should just keep the existing issue or fix it all

<vtnerd> or else I misunderstood the logic, but I think Ive got it

<jeffro256> me: A version compatibility testing framework. Supports cross-version compiling, functional testing, and Python<->C++ FFI. Trying to make the UX for writing and running tests very easy so people actually use it. Will publish first commit by EoW

<vtnerd> also serialization stuff

<jberman> me: finished hot-cold PR review (that was merged! 🎉 huge effort by @jeffro256:monero.social), working on rebasing the FCMP++/Carrot development repo on top of latest master

<jberman> in prep for beta v3

<jeffro256> Huge review effort too. Thanks to j-berman, selsta, thomasbuilds, et al

<gingeropolous> Me: posted before start, but turns out there's a buffer cap in shadow that was limiting the rpc peer list pull . Testing now

<ack-j:matrix.org> I reached out to the author who may join us during next weeks meeting > <@ack-j:matrix.org> ieeexplore.ieee.org/abstract/document/11676613

<rucknium> Thanks, @ack-j:matrix.org

<rucknium> 3. Tehrani & Tovanich (2026) "MoneroVis: Visual Analytics for Exploration and Traceability in a Privacy-Preserving Blockchain" (dnvie.com/docs/MoneroVis.pdf)

<rucknium> With us today we have Daniel Nikbakht Tehrani ( @dnvie:matrix.org ), the lead author of the paper. Welcome!

<dnvie:matrix.org> 👋

<rucknium> @dnvie:matrix.org: Do you want to briefly summarize the paper and tool?

<dnvie:matrix.org> At a high level, MoneroVis is an open-source visual analytics tool we built to help explore and inspect Monero transactions across different levels of detail, from live mempool and block monitoring down to ring structures and monetary flows. It is worth stressing that we do not introduce any new heuristics or tracing algorithm [... too long, see mrelay.p2pool.observer/e/mbvTpasLQVhyd2Jl ]

<rucknium> A live instance is running at monerovis.com . Open source code is at github.com/dnvie/MoneroVis

<dnvie:matrix.org> Looking ahead regarding FCMP++, it is important to note that we know ring-based heuristics will become obsolete. So while MoneroVis is useful today for inspecting and auditing the current protocol, we know that, at least in its current state, most of its features will not be usable after the upgrade

<dnvie:matrix.org> Also, for a brief description of the main features, please refer to the README in the github repo: github.com/dnvie/MoneroVis/blob/main/README.md

<rucknium> I want to caution anyone who wants to look at their own transactions that monerovis.com could be logging queries (but we hope it doesn't 😉). So be careful of privacy. Interested users can run their own instance of MoneroVis on their own machines for better privacy.

<dnvie:matrix.org> Yes, in theory i could see all of the data, so please self host. Also, it is currently running on a rapsberry pi, so I am unsure how many concurrent users it can even support

<articmine> Can the user control the ring size

<jeffro256> No, not since many upgrades go

<jeffro256> *ago

<jeffro256> Ring size for all v16 txs is fixed at 16

<ack-j:matrix.org> @dnvie:matrix.org: were you able to use monerovis to identify any recent true spends?

<articmine> I mean on Monero Vis

<rucknium> @dnvie:matrix.org: It seemed pretty fast, even over a Tor connection. I admire that because my data webapps are usually slow 😅

<dnvie:matrix.org> @ack-j:matrix.org: We only used the WannaCry funds as a case study so far

<dnvie:matrix.org> @articmine: What exactly do you mean with controlling ring size on MoneroVis?

<jeffro256> This is a cool visualization, and I like the "notable ring member" notices, although marking every coinbase member will probbly result in a lot of false negatives

<articmine> Simulation of different ring size for impact on the accuracy of heruistics

Cool tool. Did you implement P2Pool miner sweep detection? p2pool.observer/transaction-lookup

<jpk68:matrix.org> @jeffro256:monero.social Do you still have a link to the transaction with the highest recorded ring size?

Although it will require real-time tracking of P2Pool chains

<jpk68:matrix.org> I lost the TXID, apologies :)

<rucknium> It could be interesting to also reproduce analysis of a more recent case (which has the more advanced Monero protocol features): moonstoneresearch.com/2023/11/03/Postmortem-of-Monero-CCS-Hack

<articmine> I see use outside of Monero for MoneroVis

hi, me: chipping away at wallet2 hardening PRs as LLMs flag stuff

<dnvie:matrix.org> sech1: No

<rucknium> And that analysis would end up with "the trail runs cold". But at least it uses the output merging heuristic in the beginning.

<dnvie:matrix.org> @rucknium: Interesting, I will take a look at this

<dnvie:matrix.org> @articmine: No, you can only use “live” blockchain data, no simulations

<jeffro256> @jpk68:matrix.org: Uh I should yeah. Gimme a sec

<rucknium> @jeffro256:monero.social: So you are about to break MoneroVis :D

<jeffro256> Max observed total ring members in any one transaction on the main chain is 4524 in f901cb282db0104f33d884fc01f751cd0846a3c20dc35c37ed47f6bb1d1f8af0. Max observed ring size in any one ring on the main chain is 4501 in 5e75b4596c234ad17d34c44c3f07da508afb985748b3066bbfe2923cedb0b81a.

<rucknium> IMHO, you could add this to the README and monerovis.com. It discusses caveats to blockchain analysis, including for Monero: Deuber, D., Ronge, V., & Rueckert, C. (2022). "SoK: Assumptions Underlying Cryptocurrency Deanonymizations." Proceedings on Privacy Enhancing Technologies, 2022(3). (moneroresearch.info/97)

<rucknium> I assume the paper is in its final state, so it cannot be edited at this point.

<dnvie:matrix.org> @rucknium: Will do

<dnvie:matrix.org> @rucknium: correct

<jpk68:matrix.org> @jeffro256: Browser tab with that open is using 790 MiB of RAM ;)

<rucknium> You say

<rucknium> > MoneroVis visualizes multiple probabilistic heuristic cues without assigning calibrated confidence scores or asserting a true spent input, since ground-truth inputs and thus reliable false-positive rates are generally unavailable for real transactions. Instead, the value of the tool lies in supporting the exploration of money flows and reasoning under uncertainty.

<rucknium> IMHO, that's not completely true. I've done it at least twice: 1) Discussion Note: Formula for Accuracy of Guessing Monero Real Spends Using Fungibility Defects (github.com/Rucknium/misc-research/b…-spend-with-fungibility-defects.pdf) 2) github.com/Rucknium/OSPEAD

<rucknium> You don't need ground truth to estimate probabilities.

<ack-j:matrix.org> @dnvie:matrix.org: you may find this interesting, as I collected a lot of the same heuristics into a DB. The paper is also hard to find as it was never published :/

<ack-j:matrix.org> github.com/ACK-J/Monero-Dataset-Pip…rtificially_Intelligent_Attacks.pdf

<articmine> @rucknium: This can be a highly controversial subject in Bitcoin.

<articmine> In fact the reliability of these money flow heruistics is currently the subject of an appeal before the US Court of Appeals DC circuit

<articmine> This is I consider this very valuable research

<dnvie:matrix.org> @rucknium: That’s a fair point, you’re right that you can estimate probabilities and model bounds without labeled ground truth. In the paper, we were speaking more from the practical design perspective of the visual interface. We chose not to assign confidence scores to ring members to avoid users treating them as defi [... too long, see mrelay.p2pool.observer/e/vuGYpqsLdnNrN0Rh ]

<dnvie:matrix.org> @ack-j:matrix.org: Thanks for sharing!

<rucknium> @dnvie:matrix.org: I may give some followup questions and comments after the meeting if you don't mind.

<dnvie:matrix.org> @rucknium: Sure

<rucknium> More questions and comments for @dnvie:matrix.org for now?

<articmine> I will wait for after the meeting

<sgp_> thanks for calling them "poisoned outputs" not some other weird name

<rucknium> Monero has multiple names for everything :D. Did you know that the Monero code refers to decoys as "fake-outs"?

<rucknium> @dnvie:matrix.org: Thanks for your work and for attending the meeting, @dnvie:matrix.org !

<dnvie:matrix.org> @rucknium: Thanks for having me!

<rucknium> 4. 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/7quppqsLTHFpVXo3 ]

<sgp_> The prior topic of rings needing replacing moves us nicely into this topic, of another security audit of Monero's FCMP++ circuit

<rucknium> @sgp_:monero.social: That's next agenda item. I want to get any updates on the full picture before that

<sgp_> ah sorry :) I'll wait

<sgp_> I misread

<jberman> With the hot-cold implementation ready for testing, now working on rebasing the FCMP++ branch on top of latest master. Then we'll take care of final beta v3 tasks, and UkoeHB can also continue with getting multisig rebased on top of the latest as well (once we're back on master)

<jberman> Final beta v3 tasks after would be: rolling back the chain automatically for anyone using beta already, setting the higher min penalty zone, and any other beta specific PR's necessary. That's all very minor work. The rebase on master is taking a bit since there have been a lot of changes (plus noted what looks like a regression in the FCMP++ Rust lib working on with @kayabanerve:matrix.org )

No plans to include RandomX v2 into beta v3?

<jberman> Is that ready?

There is a PR to master branch

Which hasn't received approvals yet because it does some controversial changes on top of RandomX v2

github.com/monero-project/monero/pull/10038

<jberman> do you think it's something that warrants needing rigorous beta stress testing? doesn't seem like something to necessarily hold back beta on

It should "just work", but it will need testing eventually somewhere. No necessarily in beta v3

<jberman> beta itself isn't really blocking anything upstream, so it's not a big deal to try to get this in

<jberman> I'll leave it to @jeffro256:monero.social thoughts on path forward there. I can look at that PR soonish too

<jeffro256> Sorry I haven't responded to that PR in a while. I will do that this week

<jeffro256> I need to find my flow chart files to make modifications

<jberman> Re: upstream FCMP++ integration PR's. Here are the latest 3 PR's lined up all ready for review:

<jberman> monero-project/monero #10361

<jberman> monero-project/monero #10362

<jberman> monero-project/monero #10724

<jberman> 10361 has gotten reviewed I think should be good to go

<jberman> 10362 is fairly small

<jberman> 10724 is significant, it's the FCMP++ curve tree builder

<jberman> That rounds out Phase 2 for FCMP++ integration

<jeffro256> I added a licensing library here: monero-project/monero #11288. Any thoughts tevador or tobtoht about it in general?\

<jpk68:matrix.org> I think tobtoht is gone this month

<jberman> Biggest status update on FCMP++/Carrot front is the hot-cold PR merge though. That PR was massive and the changes were significant to get that working, huge props to @jeffro256:monero.social there. Multisig will probably be the next major milestone to look for

<rucknium> More on this agenda item?

<jberman> nothing from me, should hopefully have all code ready to go for beta v3 by next week and we can schedule it at that point

<rucknium> 5. Second FCMP++ circuit review: CCS approval.

<sgp_> MAGIC Grants (with a lot of help from Berman) sent out an RFQ for a second independent audit of Monero FCMP++’s generalized-bulletproofs-circuit-abstraction, generalized-bulletproofs-ec-gadgets, and full-chain-membership-proofs, plus an initial audit of fcmp-plus-plus. We requested that the audit scope exclude both proving and multisig. The seven quotes we received are:

<sgp_> mrelay.p2pool.observer/m/monero.social/XCgmAfDllSezLXxwOoeDvmCC.png (image.png)

<sgp_> I believe that vendors 1, 2, 3, and 7 are the best qualified for this scope. My recommendation is to pick vendor 2 and for them to review proving but not multisig. The circuit review would be nice to have, whereas the multisig review is more likely to cause distraction. Plus, since it isn’t formally defined, reviewing it now [... too long, see mrelay.p2pool.observer/e/wMzxpqsLaGxSZTdv ]

<jeffro256> Seconded

I don't know how to evaluate all the options if I don't know who is behind them, what are their credentials and past work. But from the dates point of view, does it set back the FCMP++ hardfork?

<rucknium> I don't really like the anonymized review quotes. I guess this is just the way it's going to be done.

<sgp_> My understanding (berman can say more) is that it doesn't delay anything

<jberman> no none of this is likely to set back the fork, I think we're bottlenecked by getting all the code actually completed and merged at this point, not Research audit

<sgp_> Anon encourages people to apply instead of "punishing" them. If a vendor wants to say "I am this one" then that's fine with me. We're working on an RFQ platform and as part of that, we can have a feature for people to say they are ok being named publicly like this, but I don't want to assume and risk a relationship

Any comments about the high quote of 3?

<sgp_> They are highly qualified but cost way more

So in general then, not only for this review?

<articmine> Who is actually aware of the identity of the bidders

<sgp_> Berman, Jeffro, and kayaba

<jberman> I personally liked 1 and 3 as well, but candidate 2 also seems highly qualified based on past work they've done and so it makes sense to go with them considering the quote

<jberman> and I agree on including prover but not multisig

<jberman> @sgp_: I also think this is valid reasoning for not naming the vendors publicly. obviously this makes it a bit challenging for everyone else to evaluate though, heard on that front

<sgp_> If a long-time community member wants the table, you can DM me, just keep it private please out of respect for the bidders

<rucknium> More questions and comments on this before approval is attempted?

<sgp_> I DM'd to you @rucknium:monero.social and @articmine:monero.social

<rucknium> Thanks.

<articmine> Thanks

<rucknium> My honest opinion is I am not 100% comfortable with #2

<rucknium> I don't intend to strongly influence the decision, but I need to give an honest opinion here.

<sgp_> @rucknium:monero.social: is there another one you are more comfortable with?

<sgp_> #2 has some of the best overlapping experience with frameworks specifically, not just the proofs. 1, 2, 3, and 7 have experience with frameworks

<articmine> @sgp_: Is this the opinion of Berman, Jeffro and kayaba?

<articmine> If so I am free

<articmine> Fine with not knowing the identity of the bidders

<kayabanerve:matrix.org> I preferred 2, excluding multisig

<jberman> I didn't firmly evaluate that they necessarily had the best experience. I felt that they all had the requisite experience. Not to argue against that claim, I just can't say

<rucknium> @sgp_: #1 looks good to me.

<kayabanerve:matrix.org> I preferred #7 after #2, and therefore over #1, FWIW

How would we weight that we don't have start date yet from 1?

<jberman> I don't think start date is highly relevant, I think we can very comfortably say it won't delay anything either way

Ok

<sgp_> I forgot to add theirs to the chart. It is Sept 30 - Oct 30th. So in line with the others, so time isn't a meaningful factor

So maybe not a bad idea to let this ripen for a week more?

If that's ok with the bidders ...

<sgp_> My 2c is that in terms of a quality review, 1,2,3, and 7 are all good choices. If money was no object, maybe I’d slightly lean 3. But with money as the tie-breaker consideration, I kinda have to recommend 2

<sgp_> More scope covered by a competent reviewer for less money? Yes please

<sgp_> I would delay a week but I don't think we will learn anything new that influences the decision

<rucknium> I think things seem at least narrowed down to 1, 2, 3, or 7

<sgp_> Maybe we can get approval for any of those and you can make your case for 1 outside the meeting Ruck? Ideally within the next 24 hours or so? The four of us initially settled on 2 before the meeting but if you have stuff to share that would be great. I don’t want to delay things just to delay them though

<rucknium> I hesitate to say this, but to those who know the firms' names: I assume you know why I am not 100% comfortable with #2. Anyway, I said that I didn't want to influence this much since it's not in my area. Other than me, it seems people here are ok with #2

<rucknium> #1 has also been discussed as a good option for a while, prior to now.

<jpk68:matrix.org> For those of us who are not well-informed, is it because #2 is a less reputable vendor?

<jpk68:matrix.org> Apologies if this is a dumb question :)

i dont understand the anonymous quotes when 1 person (or more) knows exactly who they are and are offering feedback to their qualifications :D

<rucknium> @sgp_: I am OK with tentative approval for #2. Then I will make my case in private.

<rucknium> I suppose the alternative to this process is to not have a public discussion of which vendors, and just let @jberman:monero.social , @jeffro256:monero.social , and @kayabanerve:matrix.org decide alone. So this process is a little more open than it could be.

<sgp_> Yeah the "normal" process for this would be a committee discussion, but it's more open out of respect for the CCS donors to know that their donations are being used wisely and for its intended purpose

<rucknium> We can attempt consensus on #2. I don't know how to word the "tentative" part to put it into a proposal statement.

<sgp_> "approval on 2, with an opportunity to reconsider based on what ruck says" ? :p

Well, I myself would continue to trust the trio of jberman, jeffro and kayaba to vote for 2, but of course your doubts, Rucknium, gives a question mark :)

<articmine> A two stage process can work. I am supporting 2 after careful review of the comments and anonymized bids

<rucknium> Proposal is: "Approve hiring firm #2 for second FCMP++ circuit review. However @jeffro256:monero.social , @jberman:monero.social , and @kayabanerve:matrix.org can choose by majority vote to bring the issue back to MRL next meeting within 24 hours."

<articmine> In favor

<rucknium> Can we get consensus on this proposal?

<rucknium> Support and any objections?

<kayabanerve:matrix.org> I approve #2 soooo

<jberman> I also approve 2

<rucknium> I see loose consensus here in favor of "Approve hiring firm #2 for second FCMP++ circuit review. However @jeffro256:monero.social , @jberman:monero.social , and @kayabanerve:matrix.org can choose by majority vote to bring the issue back to MRL next meeting within 24 hours."

<rucknium> 6. Relative locks with FCMP++ (monero-project/research-lab #161).

<sgp_> Ty Rucknium, I am eager to hear your opinion. We definitely want the best reviewer

<rucknium> I don't know if anything has changed with relative locks. IIRC, tevador and @jberman:monero.social were discussing tests.

<jberman> no update from me. I think it's fine to keep it as an agenda item in case people want to discuss. Also can be labeled "Enabling payment channels with Relative locks with FCMP++"

<rucknium> 7. FCMP beta stressnet (github.com/seraphis-migration/monero/releases). Version 3 launch checklist (seraphis-migration/monero #415).

<jberman> next item on my plate here is rebasing on top of master (and fully investigating perf changes in the FCMP++ lib), which should be done hopefully by today/tomorrow

<jberman> > <@jberman> Final beta v3 tasks after would be: rolling back the chain automatically for anyone using beta already, setting the higher min penalty zone, and any other beta specific PR's necessary. That's all very minor work. The rebase on master is taking a bit since there have been a lot of changes (plus noted what looks [... too long, see mrelay.p2pool.observer/e/no3XqKsLS29aeHJj ]

<jberman> mentioned the tasks over here. I'll hold on discussing beta until this agenda item in the future

<jberman> for IRC folk I was referring to this: libera.monerologs.net/monero-research-lab/20260916#c708186-c708187

Thanks :)

sgp_ tbh "more open out of respect for the CCS donors " would be here are the candidates and their quotes , the committee have chosen this because xyz, any objections? which is fine, its just odd when you have people like sech want to be involved and theyre looking at a $ number and nothing else

<rucknium> More on stressnet?

<rucknium> 8. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (arxiv.org/pdf/2609.10260)

<jeffro256> That's it from me

<rucknium> Finally here. And we have held on to rbrunner !

Indeed.

<rucknium> Probably best to have an initial discussion, with plans to continue in more depth next week.

<rucknium> Is @boog900:monero.social here?

<boog900> Hi

<boog900> yes

<rucknium> I am skeptical of the paper because I cannot get their reproduction code to run. However, I find their theorized attack to be plausible, given monerod's design decisions.

<rucknium> Basics: An eclipse attack happens when an adversary (who wants to do something bad) completely isolates one or more honest nodes from the rest of the network. The honest node thinks it's connecting to other honest nodes, but actually all of its peer connections are to a node (or pseudo-node) controlled by the adversary.

<rucknium> So they say they can eclipse unreachable nodes (nodes that are behind firewalls so they do not accept inbound connections) by poisoning the peerlists of honest nodes. The honest nodes inadvertently give the targeted unreachable nodes the peerlists of the adversary.

<rucknium> I think it's caused by two design decisions that may be design flaws:

<rucknium> 1. Allowing inbound connections to control the pace of adding new IP addresses to honest nodes' peerlists, specifically their whitelists.

<rucknium> 2. Limiting the white list to 1,000 peers.

<rucknium> If you fix one or both of those, you would fix the attack probably. If the attack actually works.

<gingeropolous> so far my replication attempts are confirming the findings, but I'm running into issues with shadow. Currently running what I hope is the final run.

<rucknium> The paper uses "SEED Emulator", which is supposed to be simulator to Shadow.

<boog900> monerod does have a very weak address book, it is very eager to swap out peers in the white list

Well, that magic number of 1000 sounds like a limit set in earlier time when RAM was smaller than today. Maybe no problem to lift that

<gingeropolous> Interestingly, the initial run of the entire 2.2k nodes used real monerods, and was only able to get 7/12 occupied. So if the attack was mounted using un-modified monerods, our protocol holds. But the peer list hyper injection that they did is different, and that sim is running.

you mean special nodes that "cook up" special peer lists, and fast?

<boog900> Cuprate has this issue too, but that is planed to be changed. IMO we should look at Bitcoin's address book which is much more resilient

<rucknium> The 1000-peer limit in the white list was inherited from the original cryptonote codebase: github.com/monero-project/monero/bl…f/src/cryptonote_config.h#L138-L139

<gingeropolous> essentially a synthetic node - a python process that pretends to be a monerod, does the p2p dance, and then sends bad peers

I see

<rucknium> @boog900:monero.social: The paper says that bitcoin's eviction design may be more vulnerable by nature. But they probably have patches to make it less vulnerable.

Without looking into this closely, I find it kind of counter-intuitive that this should *fully* succeed, but may there is some re-inforcement, or runaway effect in play, until the daemons are totally poisoned

I think simulations are very valuable here

<rucknium> My instinct is to just raise the white list by 10x. I don't know if that would have downsides. I haven't read all the bitcoin and ethereum eclipse papers. Maybe there is something valuable there. Or cautionary about raising the list size limit too much.

Also for later testing any changes, it might be able to inadvertantly make things worse ...

<rucknium> Ideally, if there are X% adversary nodes, only X% of honest nodes' white lists should be composed of adversary node IP addresses.

<rucknium> But they can push that up by quickly connecting to honest nodes from 1,000 adversary "nodes". Then it fills their white list.

<absinthium:4d2.org> unrelated, did the researchers that wrote the paper make any attempt to responsibly disclose their findings to us prior to releasing it?

<rucknium> @absinthium:4d2.org: Yes. They submitted a HackerOne report. They state that in the paper, too.

<boog900> I'll have to read what they said there, but Bitcoin does not give up spaces in its address book as easily as monerod which should make it slightly more vulnerable at start up but less once running with a full peer list. > <@rucknium> @boog900:monero.social: The paper says that bitcoin's eviction design may be more vulnerable by nature. But they probably have patches to make it less vulnerable.

Formulated this way, this sounds surprisingly logical :)

<rucknium> @absinthium:4d2.org: See libera.monerologs.net/monero-research-lab/20260913#c707269

<plowsof:matrix.org> bitcoincore.academy/addrman.html

<rucknium> Say that inbound connections do not get added the to the white list. Would that have an unacceptable affect on new nodes getting added to the "network-wide" white list?

<rucknium> Or say that for every peer added to the white list by in inbound connection, you would have to wait for one to be added by an outbound connection (i.e. through graylist promotion). Would that slow down the pace of the adversary packing its IPs into white lists?

Don't know, my gut feeling tells me that with drastic changes like these you can easily make things worse. But not really much more than a gut feeling.

Anyway, I guess things also have to work in edge cases, like only seed nodes ready to accept incomming connections and everybody else closed against that

<rucknium> There is a balance between letting the honest nodes establish sufficient connectivity and not letting the adversary nodes establish excessive connectivity.

<rucknium> The paper says

<rucknium> > The whitelist-filling primitive is reused from [ 44 ], and its mitigations, such as blocking whitelist insertion from incoming connections or increasing whitelist capacity, have already been discussed but remain unadopted by Monero.

<boog900> that is for the incoming connection limit from what I can see > <@rucknium> @boog900:monero.social: The paper says that bitcoin's eviction design may be more vulnerable by nature. But they probably have patches to make it less vulnerable.

<rucknium> [44] is Ruisheng Shi, Zhiyuan Peng, Lina Lan, Yulian Ge, Peng Liu, Qin Wang, and Juan Wang. 2025. Eclipse Attacks on Monero’s peer-to-peer Network. In Network and Distributed System Security (NDSS) Symposium.

<gingeropolous> i gg, but will post results when i have them

<rucknium> Thanks, @gingeropolous:monero.social

<boog900> monerod doesn't have a limit on incoming connections, so an adversary can't fill all incoming slots. But this isn't Bitcoin's address book

<boog900> Although IMO monerod should also have an incoming connection limit just for DoS prevention

<rucknium> IIRC the discussion about Shi et al. (2025) went like this: Vulnerabilities were patched, but the bigger discussion was not instigated because there was little to worry about after the patches.

<rucknium> @boog900:monero.social: I see. They mean "eviction" as in connection eviction, not address book eviction. I was confused because they mention Ethereum's incoming-connection limits like it is something different from what bitcoin does.

<rucknium> > s. In Monero, for example, the lack of

<rucknium> > an eviction mechanism [44 ] prevents an attacker from actively

<rucknium> > expelling honest connections, and the absence of a strict cap on in-

<rucknium> > coming connections makes it difficult to block new honest incoming

<rucknium> > peers. In contrast, Bitcoin’s eviction policy [ 2, 25 ] and Ethereum’s[... more lines follow, see mrelay.p2pool.observer/e/753XqasLdHZkMUVX ]

Seems to me that there is quite some stuff to study and fish for good ideas :)

<rucknium> @boog900:monero.social: I am hesitant to just have Monero copy what Bitcoin does. Maybe by accident a more resilient design could come out of the cryptonote protocol :)

<rucknium> Not to mention the risk of replacing big chunks of critical code

<boog900> Yeah I only got it from the link [2]: github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md

By the way, if they want maximum harm, or maximum damage, what will the adversary do with those fully eclipsed nodes?

I mean, yeah, stopping all transactions from propagating, but is there more?

<rucknium> rbrunner: Either complete spying on origin of tx or completely make the nodes unusable.

<boog900> @rucknium: I agree but Bitcoin does have a much better address book IMO I have looked into its logic from a high level. We don't need to copy everything but some core parts would help us a lot.

<rucknium> Unreachable nodes are the majority of the network, probably. Many of them are users at home with the Monero GUI wallet.

<boog900> like only removing unreachable peers from the white list

<rucknium> This is a good paper on many network-level attacks, including eclipse: Franzoni, F., & Daza, V. (2022). "SoK: Network-Level Attacks on the Bitcoin P2P Network." (moneroresearch.info/232)

<rucknium> We can continue discussion on this paper next week. Any last thoughts?

Hmmm. So worst case somebody could quietly establish something like a network on top of the real network, and over time spy on everything.

Ha, we are all living in the Monero network matrix already :)

<rucknium> Like mentioned prior to the meeting, the paper says rbrunner 's recent patch increased the cost of the attack: p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes' monero-project/monero #9939

But maybe hard to achieve further improvements on the selection front. Better list management is probably wide open for improvements compared to that

<rucknium> We can end the meeting here. Thanks everyone.

<rucknium> I guess you could figure out if you are eclipsed by doing a full network crawl once daily. Then if most of the network disappears from one day to the next, you know you've been eclipsed.

<rucknium> But what if the adversary does it gradually?

<rucknium> @jberman:monero.social and @jeffro256:monero.social : I invited you to a Matrix room

<vtnerd> You can ask anyone in the chat of hash+block#. Assuming the goal is fake blocks, it's hard to completely fake all avenues of checking that. Additionally there's the hashpower which would be lower