Nostr notes by MoneroResearchLab

SyntheticBird: New Cuprate blog post on RPC Hardening, Monero ...

2026-10-25T16:49:33Z

SyntheticBird: New Cuprate blog post on RPC Hardening, Monero HTTP stack mitigations and its past vulnerabilities, including the 2025 zero-day DoS campaign:
https://cuprate.org/blog/turns-out-it-is-hard-to-secure-a-web-server/

Performance impact of growing white_list to ~45k peers appears ...

2026-10-22T04:32:56Z

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: https://github.com/monero-project/monero/pull/11527
rucknium: thomasbuilds asked his LLM bot to write some performance tests. I ran them myself and wrote this in #monero-research-lounge: https://libera.monerologs.net/monero-research-lounge/20261020#c715580-c715601 https://matrix.to/#/!zxoYuvZdPYtIuWSQnn:monero.social/$R8_SLuB2_WqhPKgBzn84jp4mbpNCzvoRHPDcKf7PGEc?via=matrix.org&via=monero.social&via=unredacted.org
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: https://libera.monerologs.net/monero-research-lounge/20261020#c715580-c715601 https://matrix.to/#/!zxoYuvZdPYtIuWSQnn:monero.social/$R8_SLuB2_WqhPKgBzn84jp4mbpNCzvoRHPDcKf7PGEc?via=matrix.org&via=monero.social&via=unredacted.org
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.
https://libera.monerologs.net/monero-research-lab/20261021#c716049

quoting
nevent1q…vh9e
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
nevent1qqsrp33n6lrneqdzkrq3nmepcy4xhqya2qf9gsfeumn54jxvl720x0qude7vx

rucknium reviewed shared attack code (LLM-heavy, grid-search on ...

2026-10-22T04:28:48Z

rucknium reviewed shared attack code (LLM-heavy, grid-search on stubborn mining; OK but not amazing) and argued more exhaustive analysis (MDP or RL-MDP) is needed before endorsement; monerosim is useful but cannot cover all scenarios. tevador updated SoP last week (gingeropolous independently found a fixed issue) and will freeze specs unless a major issue appears. Biggest potential issue is temporary network splits from subjective fork choice (limited compared to PoP). gingeropolous plans more monerosim runs + LLM attacks. Clarifications: colliding minor_version shares → first-seen enters pool (other can be timestamped); fork choice only on new block or new chain (not every share, to avoid thrashing). monerosim optimizations make it runnable on consumer hardware.

rucknium: I looked a little into the code that the researcher here shared with me: https://github.com/monero-project/research-lab/issues/146#issuecomment-5978803129
rucknium: It was nice of them to share the code. IMHO, the code is OK, but not amazing.
rucknium: It looks like there was heavy LLM usage.
tevador: I made some updates to SoP in the last week. gingeropolous: thanks for the report, it seems you independently discovered the issue I fixed yesterday.
rucknium: They try to attack the protocol with stubborn mining and sort of do a grid search of possible parameters that could give the adversary an advantage.
rucknium: IMHO, it would be premature to endorse SoP without a more exhaustive analysis, like putting it into an MDP (Markov Decision Process).
rucknium: I think that if you leave stones unturned, a nasty strategy could be lurking under one of them.
rucknium: And that's the same weakness with gingeropolous 's experiments. AFAIK, there is no way for monerosim to simulate enough scenarios to try to cover everything.
rucknium: But monerosim is useful for catching other issues, like the block minor version.
gingeropolous: oh i will drive the bots to find all the stones
tevador: Agreed. People can release their LLMs on it. I'll freeze the specs for now unless a major issue is discovered.
rucknium: The selfish mining strategy against Nakamoto consensus was developed first. Stubborn mining was a small improvement. Then, MDP was deployed against the problem and a little more profit was squeeze out of Nakamoto consensus for the adversary.,
rucknium: gingeropolous: What's your plan for that?
selsta: tevador: jeffro256: this is the LLM proposal, hopefully it's not too sloppy https://www.irccloud.com/pastebin/863OFA8r/
tevador: I think the biggest potential issue of SoP is that the network temporarily splits due to the subjective fork choice rule. The attacker can induce this by release a block at the boundary of being late. But this is a trade off. But unlike PoP, the split is quite limited (1 block + 32 workshares)
rucknium: IMHO, what's needed is to put SoP into an MDP framework and count the states. If there are too many states to fully solve, then you could try a modified MDP with reinforcement learning. Modified MDP with reinforcement learning has been used recently for more complex selfish mining countermeasures that have too many states to feasibly solve in traditional MDP.
gingeropolous: current plan is to run the sims with the new spec, and then direct the llm to attack it. But yeah a more formal approach would be welcomed. i could probably plug in that paragraph and it would get to work
rucknium: Sounds good.
rucknium: More on this issue?
gingeropolous: yeah 2 questions
gingeropolous: it was in the note. When two miners find a pool share for the same slot (same minor_version), does each count, or one per slot? We'll count one, first seen.
gingeropolous: Should a share arriving re-run the fork choice, or only a block? monerod only re-runs it on blocks, so that's what we'll do first, and we'll measure how often a share would have changed the outcome.
jeffro256: selsta: This has several issues, I can DM later
tevador: If two shares have colliding minor_version, only the first one seen enters the workshare pool.
gingeropolous: awesome thanks
tevador: But the other one is can also be counted as "seen" with a timestamp for the lateness check.
tevador: For the fork choice, my intention was to run it only when a new block or a new chain is received.
tevador: I think recalculating with every share has the potential for nodes to switch between 2 chains too often.
tevador: We can see if this can have some unforeseen effects, like nodes stubbornly sticking to one chain and refusing to switch.
gingeropolous: yeah. endless sims! I also encourage folks to run monerosim on your own. recent optimizations bring scale to general consumer hardware... you don't need a 1tb ram monster for most stuff
https://libera.monerologs.net/monero-research-lab/20261021#c716018

quoting
nevent1q…pz8x
Share or Perish (selfish mining mitigation): https://github.com/monero-project/research-lab/issues/146
nevent1qqsp4vuyj6rklvd2q8yuk9vex9zd5xwnrur9rau6neuzfd0rwum5w9q7mnndv

tevador opened PR #507 (base branch fcmp++-stage is correct). ...

2026-10-22T04:25:19Z

tevador opened PR #507 (base branch fcmp++-stage is correct). Lock time increased to 3 days for better UX (e.g., Friday force-close allows until Monday). jberman will review and include in upstream PRs; concept has had sufficient time for objections. Prior conflicting issues no longer apply after recent changes.

rucknium: Since last time this was discussed, tevador made the PR: https://github.com/seraphis-migration/monero/pull/507
tevador: I'm not sure if the base branch for the PR is correct. It should be whichever branch gets the consensus changes.
tevador: It would be nice to have it reviewed and merged for the audit.
jeffro256: Base branch of fcmp++-stage is good
jberman: Ya I made some changes over in in the upstream PR's that would conflict with this, and the issue UkoeHB pointed out in #445 shouldn't apply after those changes
tevador: Btw, I decided to increase the lock time to 3 days, which is more user friendly (channel force close on Friday gives the user until Monday to react).
jberman: I can review it and get it included in the upstream PR's as well. At this point this concept has had quite a bit of time for people to voice objection to payment channels imo
tevador: Thanks
https://libera.monerologs.net/monero-research-lab/20261021#c716008

quoting
nevent1q…r7th
Relative time locks: https://github.com/monero-project/research-lab/issues/161
Consensus code: https://github.com/seraphis-migration/monero/pull/507

mx25519 merged. Upstream consensus integration PRs open for ...

2026-10-22T04:19:20Z

mx25519 merged. Upstream consensus integration PRs open for review (LLM comments addressed). RFQ for phases 2&3 integration audits out and quotes being fielded. Circuit + gadgets Least Authority audit ongoing. Multisig and Carrot tx proofs (prior item) in progress. Astra/LLM proposal for self-send receipts raised concerns about leaking k_v and breaking PQ migration; selsta to refine. Scope documents for audits available via sgp_ if needed.

jeffro256: mx25519 got merged yay!
jberman: FCMP++ upstream consensus integration PR's open for review, LLM comments all addressed
selsta: Astra suggests self-send receipts using a per-output opening secret plus a k_v signature, with the commitment explicitly binding both address keys and the transaction context as a potential C
jberman: RFQ for phases 2&3 integration audits has gone out and we're fielding quotes
jberman: Circuit + gadgets Least Authority audit is ongoing
jberman: Multisig in progress
jberman: Carrot tx proofs also in progress (the prior discussion item)
jeffro256: selsta: This would probably break the PQ migration by leaking k_v
interestingband: LOL
interestingband: jberman: Is it possible to public anywhere scope for the upcoming or ongoing audits ? Ideally as is ?
interestingband: I mean what exactly will be audited
jeffro256: Unless A) I'm misunderstanding what's being proposed, or B) there is some way to indirectly bind such that the switch commitments property is held and doesn't reveal k_v directly
interestingband: human friendly from is ok too
jberman: sgp_: want to share the doc sent out for the RFQ? That doc clarifies scope
interestingband: I just needed that for evaluation of what is audited and what is not
selsta: jeffro256: will let it refine with your concern and double check
jberman: sgp_: RFQ for both the integration audit + the ongoing circuit + gadgets audit would be appreciated (looking for the latter rn)
tevador: selsta: It would be nice to have it output a proper formalization using Carrot notation. I did not quite get what the AI is proposing.
selsta: tevador: will send it in a paste
https://libera.monerologs.net/monero-research-lab/20261021#c715994

quoting
nevent1q…0mgm
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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsd76d69wklpydmgd2stpuy8mg4nuesu0j0gesmw37xv52krwfdszs8c5839

3. get_tx_key/check_tx_key doxes sender in 2-out tx ...

2026-10-22T04:15:35Z

3. get_tx_key/check_tx_key doxes sender in 2-out tx (https://github.com/monero-project/monero/issues/11586)

The issue (also impacting Carrot) allows a third party who knows the sender’s primary address and receives the tx key (or equivalent d_e) to identify the change output in 2-out transactions and infer the sender. It was previously noted in the CLI user guide. Discussion covered why audits missed it (long-standing technique, UI convenience of tx keys over proofs, incomplete usage context), the higher impact in Carrot (automatic d_e learning by every recipient), proposed mitigations (extra ephemeral pubkey, drop Janus protection, research-lab Janus alternatives, external self-send removal, alternative InProof constructions), and the practical preference for wallets/services to switch to proper proofs rather than rely on deprecation alone. External self-sends exist mainly for self In/OutProofs. No immediate decision; further thinking / next week. Post-meeting note that Carrot has a separate change-derivation path so the issue is limited to legacy wallets.

syntheticbird: The more you learn, the more you learn
jeffro256: Spec PR is here: https://github.com/jeffro256/carrot/pull/16
interestingband: The 1st question is why it wasn't captured during audit ?
jeffro256: I should have a carrot_core PR open in the next couple days
jpk68: jeffro256: Will carrot-rs be updated for this, and the earlier re-binding change?
jeffro256: interestingband: I have also asked myself this. My guess is that since it's a technique that was sort of implied in the spec, and used in existing Monero code since forever, it was easy to overlook
tevador: Is there a reason to support external change enotes? Jamtis only has internal self sends.
interestingband: My guess ? Ask Opus 5.5 or any other AI
interestingband: it was rhetorical question, LOL
jeffro256: tevador: So you can make InProofs/OutProofs to yourself. Not much else AFAIK
syntheticbird: Terrible: Your worst enemy (AI) actually has a great point.
tevador: I think it would be better to remove the external self sends entirely.
ofrnxmr: My 2c is that the specific get/check txkey doesnt really need to be deprecated, just that wallets and providers need to stop using it for public proofs (it is a secret key), ans should he giving users a more simple route to tx proofs. (like displaying it on the same page as the tx)
syntheticbird: ofrnxmr: let's make the "trusted nodes" checkbox useful
rbrunner: You mean rely somehow on the goodwill of everyobdy doing apps on doing the right thing?
jeffro256: Yeah I was honestly impressed that Claude found the issue
tevador: In Carrot, every recipient learns the d_e, this is unrelated to tx key proofs.
selsta: https://github.com/monero-project/monero-site/blob/7dd3c296b47cecd680dec091cb19fecc1714b0eb/_i18n/en/resources/user-guides/monero-wallet-cli.md#L96-L100 so it appears this issue was documented in CLI user guide
rucknium: rbrunner: I agree with your sarcastic meaning. Only way to prevent services from using it is to make it very difficult, and make the upgrade path easy.
interestingband: jeffro256: It has been discovered 5 years before that review in my local environment by the same model by accident in the very beginning, but it felt like it's not the biggest thing I'm gonna discover in the end
jeffro256: tevador: How is it unrelated? d_e is the analougue of the tx_key in Carrot
selsta: > Note that this third party, if knowing your own address, will be able to see how much change was returned to you as well.
interestingband: Also I'm not sure how you can reason what about the fix without having a big picture how your protocol is gonnab be used
ofrnxmr: rbrunner: No, i mean its a misunderstanding. Everyone copied their homework. Wallet A provided keys, and never proofs, so wallet B did as well. We just need to talk to the wallet providers (and bisq, onion explorer etc) and have them support proofs
interestingband: That's the main reason why audit didn't capture
tevador: I mean it's unrelated to any use of the RPC to share the tx key, it's automatic. Apologies for bad phrasing.
syntheticbird: selsta: well that kinds of breaks the whole claude is smart myths all of the sudden
syntheticbird: if it was documented already
jeffro256: tevador: Oh yeah I see, yeah that's why it was much higher impact than the existing issue
tevador: That's the main reason why it needs to be fixed in Carrot. It's no longer "be careful when sharing your tx key".
ofrnxmr: rucknium: Its not actually a huge leak iiuc. The service needs to know your primary address, and there cant be a subaddress as a recipient (iirc)
jeffro256: selsta: Ah nice. NGL I've never looked at this guide in my life, but it's interesting that someone knew about it, but didn't think to put that notice anywhere more prominent
rucknium: The service might ask for a refund address and users may put their main address in that field.
rbrunner: Not yet fully clear to me. Is this the crucial sentence on that page: "Note that this third party, if knowing your own address, will be able to see how much change was returned to you as well."
ofrnxmr: Yes
ofrnxmr: But there are 2 subjects in one. The tx key, and carrot
rbrunner: Hmm. But the "can trace the sender of transaction" part that jeffro mention in his problem description is missing
ofrnxmr: I think people evaluating carrot fix is more important
ofrnxmr: rbrunner: They can learn the value of the change output
rbrunner: Anyway, maybe pointing the way to Claude is all that was needed ...
jeffro256: rbrunner: That is sort of implied by being able to see what the receive address is of the change enote. A third-party can assume that if receiver in 2-out -> other address is change -> owner of address is sender
ofrnxmr: ofrnxmr: This is whats currently happening on stressnet for legacy keyed wallets (passively)
jeffro256: Combine this with small ring info, and smart third-party may be able to probabilistically learn info about tx graph
rbrunner: I think I start to see
rbrunner: That's why only 2-out transactions are in danger
rbrunner: Or, in most danger
ofrnxmr: jeffro256: Woukdnt the know (not assume) that the other output is change, and that the address is the owners, since that is the only combo that works
ofrnxmr: 3+ out, subaddresses, non-change, dont work (..iiuc)
jeffro256: Only 2-out is in danger b/c of the cryptographic way that the shared ephemeral tx pubkey is constructed
jpk68: So this proposed fix will make InProofs impossible for most transactions? My bad if I'm misunderstanding something
jpk68: Due to it affecting 2-out transactions
jeffro256: Yes
ofrnxmr: https://github.com/jeffro256/carrot/pull/16 << this one, right jpk?
tevador: AFAICS only InProofs for self sends will be impossible.
jeffro256: Yes?
jpk68: Is there any other potential solution without these downsides?
jeffro256: A) Put 2 ephemeral pubkeys for a 2-out tx, doubling scanning time for 2-out txs. B) Removing Janus protection
jeffro256: tevador: I need to double check, but I think so
jeffro256: Or C) something I haven't seen yet
rbrunner: Er ... just ask Claude? :)
syntheticbird: "Claude make monero post quantum. Make no mistakes"
rbrunner: Now that was a bit mean, I know
slowbeardigger: Use google gemini, ofc yall have to use the best one
tevador: Is s_sr^ctx insufficient for an InProof?
jeffro256: Yes, because an InProof prover requires that the discrete log between D_e and s_{sr} is k_v
interestingband: list requirements for this part of protocol and verify in the context of involved parties that will use InProof
jeffro256: There's isn't any ECDH to speak of in an internal scan
interestingband: any other reply is just an opinion
tevador: The purpose of an InProof is to prove that an enote was received, that's not directly related to discrete log.
jeffro256: jeffro256: And provide s_sr itself
thomasbuilds: if this is needed I'm willing to propose a fix with claude
jeffro256: tevador: It's both. It decodes a received enote, and signs a message with a Schnorr signagture using k_v as the privkey
thomasbuilds: maybe it finds C > <@jeffro256
> Or C) something I haven't seen yet
jeffro256: If you simply want to prove that an enote was received to an address for a specific amount, then yes, you can provide s^ctx_sr
jeffro256: But InProof also lets you sign messages that third-parties can't
tevador: I'm pretty sure there is a solution. It might require an extra SecretDerive call or something like that.
interestingband: thomasbuilds: It did in my case, but it wasn't isolated question
rucknium: Anything need to be decided about this issue today? Or go think and come back next week?
jeffro256: If we can use a Janus mitigation from here github.com/monero-project/research-lab/issues/62, and not reveal d_e, then that would work
jeffro256: But the mitigations which are backwards-comptible with the current addresses typically have some compute or size overhead
interestingband: You are trying to find math ops to meet algebraic equations, while cryptography requires much more and with proofs, otherwise It's all insecure
tevador: I prefer to keep the current 16-byte Janus mitigation.
tevador: It's a very good fit for Jamtis, which reuses the anchor field to encrypt the address index, which is a very efficient solution. (Pre-meeting related context:)
spirobel: sorry using tx_key was never the right solution. after supplying the key once you cant proof anymore in the future through this route ... also after wallet recovery you dont have access to txkeys anymore
spirobel: > ofrnxmr Currently most / all external services ask for tx keys instead of proofs (bisq's auto, explorers, etc). Deprecating would just be deleting the endpoints afaict, and then getting every wallet to provide proofs in their place (cake, monfluo, probably gui, feather, monerujo and every other wallet display they key on the tx details)
spirobel: i think the reason this catched on was that it was more accessible in the ui of the wallets ...
jeffro256: It affects Carrot schedule, so yes > rucknium jeffro256: ^ Should it?
interestingband: Why does it affect ? Another audit ?
jeffro256: interestingband: Decision on design change, change to Carrot spec, changes to carrot_core, integration of those changes in wider FCMP++ codebase, etc. Another follow-up audit would be good, but can be done in parallel IMO, depending on how the change is implemented
interestingband: Is it a sweet spot between small and big changes where schedule is affected but audit is still optional ?
interestingband: Or it's a sweet spot of uncertainty where nothing is clear and therefore no one knows what is going to happen ?
interestingband: LOL
jeffro256: interestingband: More this. Also not optional, but parallizable with the 6-month wait period (Post-meeting:)
UkoeHB: jeffro256: I'm not seeing this De sharing issue. Carrot has a separate path for change derivation. https://github.com/jeffro256/carrot/blob/master/carrot.md#784-one-payment-one-change-rule
ofrnxmr: It only affects legacy wallets
ofrnxmr: (i assume that section is about carrot-keyed wallets)
https://libera.monerologs.net/monero-research-lab/20261021#c715878

quoting
nevent1q…5s64
#Monero Research Lab Meeting - Wed 21 October 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1477

Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully ...

2026-10-21T04:14:28Z

In reply to nevent1q…3d42
_________________________

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
nevent1qqsrp33n6lrneqdzkrq3nmepcy4xhqya2qf9gsfeumn54jxvl720x0qude7vx

Share or Perish (selfish mining mitigation): ...

2026-10-21T04:11:25Z

In reply to nevent1q…rkwl
_________________________

Share or Perish (selfish mining mitigation): https://github.com/monero-project/research-lab/issues/146
nevent1qqsp4vuyj6rklvd2q8yuk9vex9zd5xwnrur9rau6neuzfd0rwum5w9q7mnndv

Relative time locks: ...

2026-10-21T04:09:19Z

In reply to nevent1q…ytjz
_________________________

Relative time locks: https://github.com/monero-project/research-lab/issues/161
Consensus code: https://github.com/seraphis-migration/monero/pull/507

FCMP beta stressnet: ...

2026-10-21T04:03:43Z

In reply to nevent1q…h7up
_________________________

FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
nevent1qqsrdep6gkart00hu5zh5aygqlec39kfz3fdns4zar7r3v3sckqmgjqnhgj2r

FCMP++ to-do list status Programming tasks: ...

2026-10-21T04:02:46Z

In reply to nevent1q…qjf7
_________________________

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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsd76d69wklpydmgd2stpuy8mg4nuesu0j0gesmw37xv52krwfdszs8c5839

#Monero Research Lab Meeting - Wed 21 October 2026, 17:00 UTC ...

2026-10-21T04:01:09Z

#Monero Research Lab Meeting - Wed 21 October 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1477

#Monero CLI v0.18.5.4 'Fluorine Fermi' has been released! ...

2026-10-19T19:52:42Z

#Monero CLI v0.18.5.4 'Fluorine Fermi' has been released!
'This is a minor release that includes bug fixes.'
https://www.getmonero.org/2026/10/16/monero-0.18.5.4-released.html

6.2 Anthropic oss-scanner jpk68 introduced Anthropic’s ...

2026-10-15T14:34:41Z

6.2 Anthropic oss-scanner
jpk68 introduced Anthropic’s oss-scanner (https://github.com/anthropics/oss-scanner/), described as similar to oss-fuzz: project maintainers submit a request, LLMs scan the code, and findings are emailed to addresses listed in project.yaml. Bitcoin Core, Botan, libtorrent, and OpenSSL are already enrolled. A Core Team member or tobtoht would need to submit for Monero. A draft commit adding Monero was shared. bF indicated willingness to handle any KYC requirement (whether KYC is actually required remains unconfirmed). syntheticbird raised concerns about Anthropic’s advocacy for closed and regulated AI access and the marketing value of vulnerability counts. Counter-arguments included that the service is free, that Monero can already be scanned without enrollment, that enrollment does not materially affect Anthropic’s regulatory prospects, and that the practical security value is high. ofrnxmr framed it as free audits under a BSD license. syntheticbird stated personal support for enrollment while preferring a fuller discussion at the next meeting so more participants can weigh in. No explicit opposition was recorded. Post-meeting chat continued on incentives and training-data use of code.
Relevant links:
https://github.com/anthropics/oss-scanner/
https://github.com/jpk68/oss-scanner/commit/88898203c5e9db395ceb4c13495abfd310f6a487
https://openai.com/form/codex-for-oss/
https://claude.com/contact-sales/claude-for-oss

jpk68: There's also the Anthropic thing
rucknium: Yes
rucknium: Can you explain Anthropic's oss-scanner?
jpk68: 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: Several notable projects have already been merged, including Bitcoin Core, Botan, libtorrent, and OpenSSL
jpk68: 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: 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: 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: Then Monero games its number by classifying all findings as low severity :D
selsta: IIRC bF offered to do the KYC part
thomasbuilds: it's a wrong argument afaik
syntheticbird: I meant discussion
jpk68: I slopped a draft commit for adding Monero to the repo:
jpk68: https://github.com/jpk68/oss-scanner/commit/88898203c5e9db395ceb4c13495abfd310f6a487
syntheticbird: 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 participating to this end or being pragmatic about it as a project is something to think about.
ofrnxmr: Lets not pretend that m$ isnt already doing this on github
thomasbuilds: 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: I am afraid of this
jpk68: They could just do this anyways
syntheticbird: GitHub do not make use pay more or regulate us more because we are an open source project.
slowbeardigger: They play dirty
syntheticbird: wrong analogy imo
thomasbuilds: but then they wouldn't wait that we enroll, why would they?
ofrnxmr: This is also a response to thomas
slowbeardigger: True
ofrnxmr: Anthropic scanner is free afaik?
jpk68: I don't see why Monero would be singled out here, either, in that case
jpk68: For example SimpleX is enrolled as well
thomasbuilds: yeah also if we trust google there's no reason to not trust anthropic?
ack-j: I think the threat model file in the submission needs some more work
jpk68: Good point, yes
321bob321: Until they start charging when they get market share
syntheticbird: 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: 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: 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: 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: 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: Again, irrelevant
jpk68: 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: 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: If they want to find bugs in the code, they'll scan it anyways, and our enrollment doesn't matter in the slightest
syntheticbird: the point was about publicly supporting Anthropic entity that way.
syntheticbird: of course nothing prevents Anthropic from doing what they want
syntheticbird: but enrolling in gives a form of acceptance
syntheticbird: thats all
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: 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: will it reassure you to know that I am for enrolling ?
thomasbuilds: 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: Well yeah, I'm defending opposition to a clearly misconstrued argument, no offense
jpk68: In this case, it looks like we are good to proceed :D
thomasbuilds: anyone against actually?
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
slowbeardigger: Anthropic already has studied monero code e2e, doesnt matter if we enroll
slowbeardigger: we should do what's best for monero community, thats it
slowbeardigger: if we enroll we enroll
thomasbuilds: the whole difficulty is getting enrolled btw
thomasbuilds: I told you there's no kyc
jpk68: For the umpteenth, time we don't know if there's KYC
slowbeardigger: ah, no kyc, sorry sorry
slowbeardigger: what are the requirements?
thomasbuilds: none, be important enough basically
slowbeardigger: Monero is big af
jpk68: If anyone would like to sell their soul for some free tokens, here are some links:
jpk68: https://openai.com/form/codex-for-oss/
jpk68: https://claude.com/contact-sales/claude-for-oss
jpk68: Good luck!
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 enrolling. But this follows the same pattern of responsibility diffusion with ecology, users may found everyone that participated accountable, and every projects thinks they are only a drop, but together they are the cause.
syntheticbird: So I'm bringing this up so that next meeting the most weighted contributors can decide over this duality fully aware.
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"
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
syntheticbird: 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, so they never earned any money from it (at least as far as we know), the incentive has always been marketing. They also would have no reason to gatekeep the found vulnerabilities because it is of no use for them, they are not a hacking group. Some government actors might use claude to automatically find vulnerabilities for their advantages but they are the one keeping it and making use of it.
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
ofrnxmr: Its not about vuln gatekeeping, but about using our code to train their LLMs on, which theyve all been doing
syntheticbird: 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"
https://libera.monerologs.net/monero-research-lab/20261014#c714512

quoting
nevent1q…waqq
Monero Research Lab Meeting - Wed 14 October 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1474

6.1 Share or Perish (SoP) specification questionsgingeropolous ...

2026-10-15T14:21:12Z

6.1 Share or Perish (SoP) specification questionsgingeropolous sought clarification from tevador on Share-or-Perish fork-choice rules for monerosim. The main points covered were the definition of n_f, handling of displaced blocks after a reorg, peer-ban behavior when height drops, and the interaction of a workshare count placed in version_minor with Monero’s existing hard-fork vote rule. On n_f, tevador stated that the weight becomes objective once the fork point is 48 work objects deep. On displaced blocks and potential cycling, tevador did not believe a switch can cycle because the weight does not change when chains are switched and the objective weight applies at 48 work objects. Peer bans were flagged as a problem: SoP permits a switch to a shorter chain while stock monerod permanently penalizes peers whose height drops, which can produce 24-hour bans among honest nodes. tevador questioned the rationale, noting that cumulative difficulty can also produce shorter-chain reorgs. Placing the workshare count in version_minor collides with the hard-fork vote rule used in v0.18 (blocks with an insufficient vote are rejected). boog900 confirmed the rule in documentation and code. tevador observed that SoP would require a hard fork to remove the rule if it is enforced and asked whether anyone opposed removing the rule; boog900 suggested the entire vote system could go. rucknium will place the hard-fork vote rule on the next agenda. gingeropolous is launching simulations to confirm observed behavior. tevador noted that the Python simulation code is not authoritative.
Relevant links:
https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/mrl146_briefing.md
https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/fork_choice_loop.html
https://github.com/monero-project/research-lab/issues/146#issuecomment-5978803129
https://monero-book.cuprate.org/consensus_rules/hardforks.html
https://github.com/monero-project/monero/blob/eac1b86bb2818ac552457380c9dd421fb8935e5b/src/cryptonote_basic/hardfork.cpp#L109

rucknium: We had gingeropolous 's question for tevador about the Share or Perish spec
gingeropolous: the long version (warning, ai gen): https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/mrl146_briefing.md
tevador: 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: I requested and received SoP simulation code from these researchers: https://github.com/monero-project/research-lab/issues/146#issuecomment-5978803129
tevador: 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: https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/fork_choice_loop.html
gingeropolous: yah gotta download it cause github pages are beyond me for some reason
tevador: I don't think that can happen.
gingeropolous: hrm, perhaps if i solidify Q1 in the implementation then Q2 will go away.
tevador: I don't think it can cycle. The weight doesn't change when you switch chains.
tevador: 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
tevador: 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."
tevador: 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.
tevador: 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
tevador: 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: https://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
tevador: "must" => block rejected if violated?
tevador: If we really have this rule than SoP cannot be used without a hard fork removing this rule.
boog900: yes: https://github.com/monero-project/monero/blob/eac1b86bb2818ac552457380c9dd421fb8935e5b/src/cryptonote_basic/hardfork.cpp#L109
tevador: 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.
https://libera.monerologs.net/monero-research-lab/20261014#c714462

quoting
nevent1q…waqq
Monero Research Lab Meeting - Wed 14 October 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1474

rucknium presented a minimal PR intended to give the network a ...

2026-10-15T14:00:40Z

rucknium presented a minimal PR intended to give the network a defense against the Nyx attack without prolonged experimentation. The PR does not enlarge the gray_list; participants noted that gray_list entries are not initially connectivity-checked and that multiple ports per IP are allowed, making adversarial filling easy. ofrnxmr’s work-in-progress changes bucket both lists and prevent direct injection into the white list; the patches are stacked and will be tested separately and together. White-list housekeeping is currently only “evict oldest over limit”; rucknium suggested adding proper eviction-on-no-response behavior and possibly housekeeping on every insertion to mitigate temporary VPN-based peer injection. jeffro256 proposed tracking the originator of each peer-list entry and evicting by originator proximity (ASN sorting as one possible ordering). Caching of peer lists was suggested to reduce CPU cost of repeated reshuffling and to limit enumeration attacks. IPv6 was flagged as difficult to secure without something like proof-of-storage. plowsof reported that roughly 60% of reachable nodes appear suspicious and that an adversary already controls more than 2500 addresses according to observatory data. jeffro256 viewed the current PR changes as almost strictly better in most scenarios (speed impact still to be measured). rbrunner anticipated a prolonged period of competing approaches. Ban-list updates will require a reliable fingerprint with negligible false-positive risk.

rucknium: I made this PR: https://github.com/monero-project/monero/pull/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: 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: No, its blindly evicting oldest over limit
ofrnxmr: 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: 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
rbrunner: Looks like we may enter a quite prolonged phase of experimentation and competing approaches until things finally settle ...
ofrnxmr: Also changed that they cant inject into white
rucknium: But what if an adversary controls 1,000 IP addresses, like in the Nyx attack paper?
ofrnxmr: According to plowsof's obaervatory, they control over 2500
jeffro256: 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.
rbrunner: Sounds reasonable
plowsof: 60% of reachable nodes are implicated in being sus
rucknium: Which is one of the reasons why I went for minimal changes.
boog900: semi-related to the discussion: https://github.com/Boog900/monero-ban-list/issues/18
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
plowsof: 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: it wasn't that bad
syntheticbird: I was just late of one month
plowsof: said ai research https://github.com/plowsof/crawler-research/blob/main/Monero-Peer-AS-Deduplication/pdf/monero-peer-asn-deduplication.pdf
rucknium: 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: 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" by an adversary, where the adversary can get the whole contents of the white_list by just requesting it many times.
rucknium: 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.
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: You or I could run the Nyx simulation with your patch once you finish it.
rucknium: 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: 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 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. > Where do we go from here?
ofrnxmr: Sounds good > 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: https://github.com/Rucknium/misc-research/tree/main/Monero-Eclipse-Attack/nyx/code/monerosim-config
https://libera.monerologs.net/monero-research-lab/20261014#c714392

quoting
nevent1q…ns78
Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!": https://arxiv.org/pdf/2609.10260
nevent1qqs8h38gkfa38apr90ysuqkayn2c9uk5y9awc5kvn7auycgxhhu04lcxusw9h

The beta stressnet is operating smoothly with limited additional ...

2026-10-15T13:49:53Z

The beta stressnet is operating smoothly with limited additional stress testing so far. jberman holds logs from a solid stressing period by sech1 and plans to review the latest round of transaction-relay v2 changes; if those hold up, the changes should be ready for mainnet.

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.
https://libera.monerologs.net/monero-research-lab/20261014#c714387

quoting
nevent1q…hm0y
FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
nevent1qqsq0esjy5mf262e2gzysuwuk4zwwwjtngcl9lufd354eyrnv8e2w9spzfdqq

jeffro256: mx25519 continues to be a bottleneck to HF activation. ...

2026-10-15T13:43:49Z

jeffro256: 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.
jberman: Multisig still in progress
On Research audits: the circuit + gadgets round 2 audit with Least Authority is underway
I will review PoWER within the next ~month
tevador: FWIW, I have approved Monero PR 10964. I think it only needs approval from tobtoht.
jeffro256: 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.
https://libera.monerologs.net/monero-research-lab/20261014#c714375

quoting
nevent1q…sldg
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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqs2hw472wm8dl8amkurvm6esucg9jy7qcaue7f2erv4js9uj7qn87q6kmvay

Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully ...

2026-10-13T23:17:27Z

In reply to nevent1q…qudw
_________________________

Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!": https://arxiv.org/pdf/2609.10260
nevent1qqs8h38gkfa38apr90ysuqkayn2c9uk5y9awc5kvn7auycgxhhu04lcxusw9h

FCMP beta stressnet: ...

2026-10-13T23:16:00Z

In reply to nevent1q…8c0z
_________________________

FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
nevent1qqsq0esjy5mf262e2gzysuwuk4zwwwjtngcl9lufd354eyrnv8e2w9spzfdqq

FCMP++ to-do list status. Programming tasks: ...

2026-10-13T23:15:08Z

In reply to nevent1q…y57w
_________________________

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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqs2hw472wm8dl8amkurvm6esucg9jy7qcaue7f2erv4js9uj7qn87q6kmvay

Monero Research Lab Meeting - Wed 14 October 2026, 17:00 UTC ...

2026-10-13T23:13:53Z

Monero Research Lab Meeting - Wed 14 October 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1474

rucknium re-ran the unreachable-node simulations for 50 in-sim ...

2026-10-08T03:03:47Z

rucknium re-ran the unreachable-node simulations for 50 in-sim hours because the 26-hour runs never let white_lists reach steady state. The 26-hour plot does not approach the 1,000-peer threshold; the 50-hour run almost does, as 1,000 adversary peers are slowly absorbed into the unreachable node’s white_list. The qualitative result is unchanged. gingeropolous helped speed the sims: 15 hours of wall-clock for 50 hours in-sim. Reproducible analysis, then a PR with the suggested changes, is expected within about 24 hours. Full reproduction needs a ~1TB-RAM machine; raw sim data will be included, and a scaled-down sim may follow. Status-quo runs sometimes hold a sustained 12/12 eclipse and sometimes only an intermittent one, which rucknium attributes to sim randomness and treats as a reason to run multiple trials. Prior confidence intervals: https://gist.github.com/Rucknium/ba230a2bab8a446d0997b7b002bf3af6.

rucknium: 5. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260)
rucknium: I re-ran simulations for a longer 50 hours in-sim time. I wasn't satisfied with the 26-hr simulations because the white_lists didn't reach a steady-state equilibrium.
rucknium: (white_list_unreachable.png)
rucknium: ^ This is the 26-hour run. You can see that the red line on both plots does not go up near the 1,000-peer threshold.
rucknium: (white-list-unreachable.png)
rucknium: The 50-hr run almost reaches that. There are 1,000 adversary-controlled peers. It takes a while for them to be absorbed by the unreachable node's white_list.
rucknium: But anyway, the same result happens. Just wanted to make sure it worked with the longer sim time.
rucknium: (outbound-adversaries-unreachable.png)
rucknium: gingeropolous helped make the sims run faster. We are at 15 hours of wall-clock time for this 50-hr in-sim time simulation.
rucknium: I've been working on making the analysis reproducible. It is sometimes surprising how much time it can take to gather scattered scripts and data and write understandable reproduction instructions. But if it's not reproducible, it's not science! Once I'm done with that, which should be within 24 hours, I'll make the suggested changes as a PR.
rucknium: Well, it won't be "easily" reproducible from scratch if you don't have a 1TB-RAM machine. But I will include the raw sim data. I may try to create a scaled-down sim that should show the results, after making the PR.
rucknium: That concludes my update on this agenda item.
rucknium: Actually, one more thing. gingeropolous and I notice that sometimes the status quo sim results in a sustained 12/12 eclipse, and sometimes only intermittent 12/12 eclipse. I think that's because of randomness in the sim. That just brings up why running the sim multiple times can be important. In this simulation case, the outcomes for the status quo and proposed defense simulations are so different that I think doing statistical inference with multiple simulations each probably isn't completely necessary.
rucknium: This is where I did multiple simulations and estimated confidence intervals on outcomes, previously: https://gist.github.com/Rucknium/ba230a2bab8a446d0997b7b002bf3af6
jeffro256: Ruck is CGO: chief graph officer

https://libera.monerologs.net/monero-research-lab/20261007#c713326

quoting
nevent1q…px69
Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!": https://arxiv.org/pdf/2609.10260
nevent1qqswyt808xtymr98k5ghuqp9l7lvsgmp7jn9euxq7cfjecnrfq4p9nc2955qd

The stressnet has forked. rucknium’s monitors are up and quiet ...

2026-10-08T02:53:41Z

The stressnet has forked. rucknium’s monitors are up and quiet after sech1 stopped filling 10MB blocks so the chain would not grow too fast: https://stressnetnode1.redteam.cash/ https://stressnetnode2.redteam.cash/. jberman said the two notable beta v3 issues so far are GUI binary plumbing, with a known fix that still needs to be ported. ack-j offered to deep-scan closed FCMP PRs (https://github.com/monero-project/monero/pulls?q=is%3Apr+label%3Afcmp%2B%2B+state%3Aclosed); jberman agreed, and asked for a comparison against master.

rucknium: 4. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/).
rucknium: We have forked!
ack-j: jberman: do you think it would be worth while if I ran the same deep scan on the closed fcmp PRs?
ack-j: https://github.com/monero-project/monero/pulls?q=is%3Apr+label%3Afcmp%2B%2B+state%3Aclosed
rucknium: My stressnet monitors are up. Not much going on at the moment: https://stressnetnode1.redteam.cash/ https://stressnetnode2.redteam.cash/
rucknium: sech1 was tx spamming and filling 10MB blocks for a while, but he stopped so the blockchain didn't grow too big too quickly.
jberman: on beta v3: so far the 2 notable reported issues I've seen are just from GUI binaries plumbing
jberman: which have a known and implemented solution already, just need to port the solution
jberman: ack-j: sure, and compare to master to see if any of it has already changed or been addressed
rucknium: Some of us are feeding gingeropolous stressnet data so some analysis can be done: https://github.com/Fountain5405/stressnetmonitor
rucknium: Discussion of stressnet is happening in #monero-stressnet on Matrix and ##monero-stressnet on Libera IRC I think.
https://libera.monerologs.net/monero-research-lab/20261007#c713314

quoting
nevent1q…v96n
FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
nevent1qqsfyk5gxg9dlkrzy8dwthqhzd83hzuzt0apkujt7nh9pw8j9rvnumcxg4ccu

FCMP++ inflation safeguards are in the open integration PRs. AI ...

2026-10-08T02:49:56Z

FCMP++ inflation safeguards are in the open integration PRs. AI review already flagged issues. Tree building stays off on master until the FCMP++ library is treated as final. It will be gated by a compiler flag (selsta’s preference) instead of a long-lived side branch. A Carrot output spent with the old signature type can get a second key image, which is an inflation risk. An earlier block on that path was not enough: a height check can overflow. The new fix is https://github.com/seraphis-migration/monero/pull/499. Dropping the 24-hour grace period at the fork would make leftover transactions fail on purpose. jberman would rather keep it and harden the interim code. Dropped payments must be recreated. Building FCMP transactions early looked riskier.On the #11425 AI review (https://github.com/xmrack/monero-review/issues/1011), the “critical” finding was a copy-pasted database snippet that tests should catch once the code is on. The unlock-time tree-growth note is moot: timelocks are already set for removal.

thomasbuilds: I can’t be there for the meeting, sharing this for potential discussion:
thomasbuilds: xmrack's AI review for 11425 flags a “critical” issue. The description seems consistent with my own second review point of the PR.
thomasbuilds: What's new though, that I haven't raised is F2 (medium), "shared custom unlock_time makes one unbounded tree growth"
rucknium: Isn't that topic better for #no-wallet-left-behind meetings?
rucknium: AFAIK here's the link for that AI review: https://github.com/xmrack/monero-review/issues/1011
thomasbuilds: as you wish
jpk68: I saw that too, and it would be good to make sure people are aware of this, but that's just me
thomasbuilds: vuln is commented out right now. but plan is to uncomment it.
thomasbuilds: https://github.com/monero-project/monero/pull/11425#discussion_r4172805190
rucknium: Looks like the meeting is going to be short, so there is room for other topics. I would defer to jberman on whether it make sense to discuss it at this meeting.
jberman: Good with me to discuss, I planned to discuss this issue https://github.com/seraphis-migration/monero/pull/499 today as well
rucknium: 3. FCMP++ to-do list status. Programming tasks. Reviews and audits. FCMP++ Integration Audit Overview. Network upgrade schedule Gantt chart.
jberman: On upstream FCMP++ integration PR's: the outstanding PR's include all code that is meant to prevent inflation at consensus. I'm working through AI reviews now, which have found some notable items
sgp_: jberman: some of the tree building code from phase 3 is commented out like we talked about, is there a reason why they shouldn't be uncommented prior to getting the quotes? Or is something blocking them or whatever
jberman: Uncommenting would have the tree built on any monerod running from the master branch. The upstream FCMP++ lib code has been modified a few times over the last months in ways that render the prior tree execution incompatible with those changes
jberman: So I was thinking it may make sense to wait until we want to declare the upstream FCMP++ lib code definitively finalized such that no future changes to the tree are expected
jberman: I could also have it be off by default with a compiler flag, and then we can remove that compiler flag later to enable
jberman: (and someone can compile with it turned on)
sgp_: would an fcmp++ branch help or would it make things even more annoying?
jberman: it would be nice to have this all on master branch sooner rather than later so it's kept at pace with the (fairly rapid) changes on master
jberman: and not expect every new PR to also be applied to an fcmp++ branch
jberman: maybe selsta will have an opinion on that too
selsta: compiler flag seems best for me
sgp_: so it's just commented only because of build related things, not because it's unfinished, that is the main thing I wanted to check on
jberman: right
sgp_: gotcha, then it's probably fine from the rfq perspective
jberman: I'll do the compiler flag as well
jberman: Re: https://github.com/seraphis-migration/monero/pull/499 . The context: Carrot outputs and legacy outputs use a distinct key image generator. If a Carrot output was to be used in a CLSAG, the code would use the legacy (biased) key image generator producing a distinct key image for that Carrot output. Thus if we allowed CLSAG with Carrot outputs, and FCMP++ with Carrot outputs, then someone could double spend a Carrot output
rucknium: What if this time there was no "double fork" 24-hour grace period? It would inconvenience users at the fork height, but maybe it would be worth it to make the process safer.
rucknium: IIRC, last hard fork, "leftover" txs were dropped anyway because of an insufficient fee bug.
rucknium: "This time, it's deliberate"
jberman: The solution in https://github.com/seraphis-migration/monero/pull/446 is to prevent CLSAG rings that contain Carrot outputs. However, it relied on the code that gets the "max height" of a ring member to be correct, and unfortunately it isn't since the ring member's id calculation can overflow and wrap around, which causes the "max height" to be set to the wrong value. The solution in 499 addresses this by preventing ring members from overflowing at the fork, and also double checking that ring member heights are increasing or the same
jberman: rucknium: I'm not strongly opposed to this. It's a nice-to-have that we still need to validate is even working correctly (and txs aren't getting dropped)
jberman: We'd essentially be saying some expected valid txs might get dropped around the time of the fork, which isn't ideal
jberman: We can do everything we can to make sure this interim fork code is airtight to make sure there isn't inflation. It does widen the surface for things to go wrong though
rucknium: What would be the risks if wallet software started constructing FCMP-compatible txs 10 blocks before the fork height?
jberman: Immediate answer is I think that would a riskier change. If we were to allow such txs into the pool early, we'd have to modify a lot of consensus critical code for verification too that has to make sure not to allow those txs into the chain until later
ap4sh: (hi) if some pending txs get dropped at the fork, will wallets recover and resend them, or will users need to recreate those payments?
jberman: they would need to recreate those payments
rucknium: AFAIK, wallet software, at least the GUI and CLI, notify users if their txs fail to be confirmed after some time. Is that true?
rucknium: This will probably be 100 txs that are ejected from the txpool if no one spams during the fork.
jberman: They notify an error if the tx doesn't reach the node's pool (or is kicked from the pool)
rucknium: Last time, someone spammed right before the fork. (Someone claimed responsibility for this at a MoneroKon or Monerotopia conference years later IIRC.)
rucknium: Does someone want to discuss this ^ topic? > thomasbuilds: I can’t be there for the meeting, sharing this for potential discussion:
rucknium: > xmrack's AI review for 11425 flags a “critical” issue. The description seems consistent with my own second review point of the PR.
rucknium: > What's new though, that I haven't raised is F2 (medium), "shared custom unlock_time makes one unbounded tree growth"
rucknium: The AI review is here: https://github.com/xmrack/monero-review/issues/1011
jberman: Personally I'd prefer not to remove the grace period fork and get this code correct. But if the idea to remove it and allow some txs to get dropped at the fork gets more support, I'm not opposed
jberman: Yea, I'll discuss that as well
jberman: That "critical" issue would've been caught immediately once the code is enabled by (multiple I'm pretty sure) tests. It's a result of a snippet of DB code that I copy pasted into a different spot from our development branch because I felt it would make the code cleaner. That was a poor mistake on my part
jberman: I made some other changes on that branch from our development branch in aims of making the code cleaner and stronger based on some comments I've gotten in different places over the months
jberman: With the compiler flag for this FCMP++ integration code, we could turn it on for tests as well. I'm also going to introduce significantly more testing that we have in our development branch already, into the upstream master branch in later PR's (because it uses prover code, and I wanted to isolate consensus changes for review to focus in on the major potential consensus issues)
jberman: If we had all this stuff in 1 PR FWIW, I'd be working through 1000 LLM comments at this point
jberman: On "shared custom unlock_time makes one unbounded tree growth": this is yet another reason to drop the timelock feature. We're settled on the retroactive deprecation date so that won't be an issue
jberman: I guess I can introduce that consensus rule into this PR as well
rucknium: jberman: That's what I thought as well. It's a moot point.

https://libera.monerologs.net/monero-research-lab/20261007#c713258

quoting
nevent1q…7zwe
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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsy0q84gne0cgj9rg46ulr0cf90euqtts8rmh3dxqvm53hk86hay7cyyssrr

Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully ...

2026-10-07T04:13:52Z

In reply to nevent1q…klpt
_________________________

Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!": https://arxiv.org/pdf/2609.10260
nevent1qqswyt808xtymr98k5ghuqp9l7lvsgmp7jn9euxq7cfjecnrfq4p9nc2955qd

FCMP beta stressnet: ...

2026-10-07T04:13:10Z

In reply to nevent1q…48wv
_________________________

FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
nevent1qqsfyk5gxg9dlkrzy8dwthqhzd83hzuzt0apkujt7nh9pw8j9rvnumcxg4ccu

FCMP++ to-do list status. Programming tasks: ...

2026-10-07T04:11:51Z

In reply to nevent1q…4q9n
_________________________

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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsy0q84gne0cgj9rg46ulr0cf90euqtts8rmh3dxqvm53hk86hay7cyyssrr

#Monero Research Lab Meeting - Wed 06 October 2026, 17:00 UTC ...

2026-10-07T04:10:07Z

#Monero Research Lab Meeting - Wed 06 October 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1470

Shi et al. (2026) “Are Unreachable Nodes Truly Safe? Fully ...

2026-10-01T03:48:01Z

Shi et al. (2026) “Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!”
Paper: https://arxiv.org/pdf/2609.10260
Proposed patch: https://gist.github.com/Rucknium/fd57fd99fc9bc985d671a6ce96cc668e
rucknium presented preliminary 26-hour monerosim runs:
1,200 honest monerod nodes and 1,000 adversary lightweight py-levin processes; 14-hour burn-in then 12-hour attack; all honest nodes reachable except one target unreachable node. One run used unmodified v0.18.5.1-release; the other used that release plus the patch.
Result: on unmodified v0.18.5.1 the adversary nearly eclipsed the unreachable node (11 of 12 outbound connections). The patch defeated the attack. Attack path: poison reachable nodes’ 1,000-slot white lists (oldest-seen eviction), then those lists infect unreachable nodes.
Unreachable nodes still had a majority of honest white-list peers at the end, but connection-selection logic still produced eclipse; increasing white-list size alone is not enough.

Status-quo selection: every 101 seconds drop one outbound and replace it; usually from very recently seen white-list peers; first try gray list, then after 3 failures try white list up to three times. The patch’s three reforms: (1) raise white-list limit to 10,000; (2) draw from white list first instead of gray list; (3) uniform random draw from the whole white list, removing the quadratic recent-peer distribution and the split logic around 8 outbound connections. Subsets of the reforms were insufficient; all three were needed.
White-list fill is slower because gray-list-to-white promotion on connection select is less common. plowsof confirmed IRC can see the images, reported ~3–4k reachable nodes recently, Peg Tech flooding gray lists (~800 IPs/many ports/~4k entries; proxy network tied to DDoS: https://www.qurium.org/alerts/denial-of-service-attacks-on-investigative-media-traced-to-yet-another-proxy-provider-2/), and tracking at https://observer.monerodevs.org/. jeffro256 supported dropping the quadratic recent distribution as centralizing even without attackers, and suggested setting the white-list limit near the real reachable-node count. rbrunner noted the quadratic bias survived the last peer-selection update. rucknium said the attacker model was held constant (a weakness), some Shi et al. suggestions are in the defense, white-list expansion has been suggested by that team since at least early last year, next step is a PR plus this analysis, also removing dead logic.
vtnerd: https://github.com/monero-project/monero/commit/b750fb27b0f20e9443827732b69a504a76036430#diff-85f0577b849d28c11a899cb863aec3df1d946e0bb214a623deef05928271fef6, original logic attempted one white then gray each time; a later while-loop change may have been worse. rucknium would support putting this defense in the next monerod release.

rucknium: I have some graphs for you! AFAIK, IRC side can get links to images. Let me know if IRC can't see the images and I will post them somewhere on the web.
rucknium: I've run monerosim simulations. They are 26 hour runs. 1,200 honest monerodnodes and 1,000 adversary "nodes" (actually just lightweight py-levin processes). I set the "burn in" time to 14 hours so honest nodes have time to find each other and fill their peer lists. Then the adversary attacks for 12 hours. All the honest nodes are reachable except for one, the "target" unreachable node.
rucknium: In theory, all unreachable nodes should be affected the same way. We just don't have more because running more nodes will start to exhaust machine RAM.
rucknium: One simulation has all honest nodes running the v0.18.5.1-release. The other has them running v0.18.5.1-release, modified by my proposed patch: https://gist.github.com/Rucknium/fd57fd99fc9bc985d671a6ce96cc668e
rucknium: I will explain the purpose of the patch after a few graphs. First, the big result.
rucknium: By the way, this is preliminary findings. I will need to double-check everything to make sure there are no issues.
rucknium: (outbound_adversaries_unreachable.png)
plowsof: DataHoarders bridge is working , IRC can see the images
rucknium: This graph shows that the adversary can nearly eclipse the unreachable node running the unmodified v0.18.5.1, occupying 11 of 12 outbound connections. My proposed patch defeats the attack.
rucknium: Thanks for checking, plowsof
rucknium: How does the attack work? First, the adversary peers poison the white_list of the reachable nodes.
rucknium: (white_list_reachable.png)
rucknium: When the attack launches in the status quo network (top plot), the adversary peers push the honest peers out of the reachable nodes' white lists because there are only 1,000 slots in the white list.
rucknium: When a new peer is inserted into the white-list that would take it beyond its size limit, the honest node drops the "oldest"-seen peer from the white_list
rucknium: On the bottom you see that no honest peers are dropped. I will come back to that.
rucknium: The honest reachable nodes then infect the unreachable nodes' peer lists. Unreachable nodes get their peer lists from reachable nodes. So the unreachable nodes keep asking the reachable nodes for their now-poisoned whitelists.
rucknium: (white_list_unreachable.png)
rucknium: In the top plot there you'll see that by the end of the simulation, the honest unreachable nodes still have a majority of their white_list occupied by honest reachable peers. So why do they get eclipsed?
rucknium: IMHO, it's a product of some "interesting" design decisions in the connection selection logic.
rucknium: Those decisions are why just increasing the white_list size limit is not enough.
rucknium: The next image has a violin plot (https://en.wikipedia.org/wiki/Violin_plot). It's a distribution density plot turned on its side.
rucknium: (peerlist_draws_reachable_status_quo.png)
rucknium: This shows from where nodes are selecting their next connection. Every 101 seconds, a node will drop one of theour outbound connections and choose one to replace it.
rucknium: There's a lot going on in this graph.
rucknium: The top part shows the position, ordered by last_seen where the node selects its next connection from the white_list
rucknium: The vertical axis is in log scale
vtnerd: doesn’t this diff you sent change the bootstrap process? or I guess the idea is just wait until the graylist housekeeping runs?
rucknium: Usually, the node selects from very recently-seen peers as its next connection.
vtnerd: because theres now a bias towards whitelist, which I guess is needed given your results
plowsof: Peg Tech are currently flooding gray lists (800~ips with many ports totalling 4k~ entries circulating. its a proxy network known for facilitating ddos attacks (https://www.qurium.org/alerts/denial-of-service-attacks-on-investigative-media-traced-to-yet-another-proxy-provider-2/)
rucknium: Exactly.
rucknium: ^ Look carefully at the slope of the honest.peers line in the two scenarios. The honest nodes' white_lists fill more slowly with my patch. > rucknium: (white_list_reachable.png)
rucknium: AFAIK, there are three ways a peer gets into the white_list:
rucknium: 1. A reachable node connects to me
rucknium: 2. I perform gray_list housekeeping (promotes a reachable node to the white_list, but doesn't establish a connection)
rucknium: 3. Directly promotes a peer from gray_list to white list when selecting from gray_list for the next connection.
rucknium: My patch reduces the probability that (3) happens, so the white_list filling is slower, but not too slow IMHO.
jeffro256: Does the patch touch the quadratic probability distribution used to pick very recent white list peers ?
rucknium: The status quo logic first tries to connect to a gray list peer. If there are 3 failures, then it tried the white list up to three times.
rucknium: jeffro256: Yes. It gets rid of it
rucknium: "Mister Chesterton, tear down this fence."
jeffro256: Cool, I always thought that it was a bad idea
jeffro256: Even without active attackers, it felt centalizing
jeffro256: But I never deep dived into it
rbrunner: That survived the last peer selection code update, from me and Rucknium :)
rbrunner: Maybe now its days are numbered
rucknium: My patch simplified the logic a lot. It eliminates the "quadratic" recent distribution and does not have a split logic flow when the node has greater than or less than 8 outbound connections.
rucknium: I didn't want to touch that logic in the /24 subnet deduplication PR because of the Chesterton Fence logic. But it's a clear danger now.
plowsof: peer list spammers are being tracked currently at https://observer.monerodevs.org/
rucknium: Biasing your connection selection to pull from the gray list gives the adversary an advantage because the gray list can be dominated and manipulated by adversaries more easily than the white list.
rucknium: So I decided to first pull from the white list instead
rucknium: And selecting only recently-seen peers from the white list makes it difficult to get out of the clutches of an adversary if you find yourself there.
rucknium: (peerlist_draws_reachable_defense.png)
rucknium: This is that same graph, but with the proposed defense patch. Almost no draws from the gray list. And the draws from the white list are spread uniformly (note the log vertical scale on the top plot).
rucknium: I don't have these graphs for the unreachable node because monerosim didn't save the info. (need to fix that). But the logic is there.
gingeropolous: blargh
rucknium: My patch ( https://gist.github.com/Rucknium/fd57fd99fc9bc985d671a6ce96cc668e ) has 3 reforms:
rucknium: 1. Increase the white_list limit to 10,000 so adversary peers cannot push out honest peers
rucknium: 2. Try to draw from the white_list first instead of the gray_list
rucknium: 3. When drawing from the white_list, select in a uniform random manner from the whole white_list instead of just recently-seen peers.
rucknium: 10,000 is arbitrary, but I have an idea of how to decide a not-arbitrary limit. Not sure if it makes sense to go into that detail here.
rucknium: IMHO, the Nyx eclipse attack is a serious concern. I would support putting a defense patch into the next monerod release.
rucknium: More defenses can be put in there, but just these changes mostly defeat the attack.
rucknium: Discussion? Questions?
jeffro256: If we could get a ground truth value for the number of reachable nodes IRL, I think setting the whitelist limit to approximately that value would make the most sense. But that's just me spit balling > rucknium: 10,000 is arbitrary, but I have an idea of how to decide a not-arbitrary limit. Not sure if it makes sense to go into that detail here.
rucknium: By the way, I tried subsets of the reforms in monerosim, but I needed all three to get the proper defense.
vtnerd: my only concern is that this doesn’t distribute the load properly, because it no longer aggressively selects from graylist. otoh, there’s already a routine to move nodes into whitelist
rbrunner: No question, but just have to say I admire your work
vtnerd: the recently seen bias is likely a good change
plowsof: ive observed 4-3k reachable the past few days
rucknium: Thanks. Couldn't have done it without gingeropolous:monero.social 's work on monerosim. Or Shi et al. for raising the issue.
rbrunner: Yes, it's really nice how sometimes everything flows together nicely
rucknium: vtnerd:monero.social: IMHO, it would be a good idea to mathematically formalize the peerlist system. Once formalized, one could try to prove that the system has some properties. Hopefully, good security properies.
rbrunner: Doesn't this diminish the importance of the grey list quite a bit?
rucknium: There is a flow of addresses around the network, from reachable to unreachable, from new to old. How does that happen? It could be formalized IMHO.
jeffro256: Have you looked into simulating new attacker models for which the proposed defense would do worse?
rucknium: Yes, but graylist is where "There be dragons"
rbrunner: I see.
rucknium: jeffro256:monero.social: No. The weakness in the analysis is that the attacker's strategy is the same for both scenarios.
rucknium: But some of Shi et al.'s suggestions were incorporated into my defense.
rucknium: Since at least early last year, the Shi et al. research team has suggested that white list limit be raised.
rucknium: Graylist should be untrusted because nothing there is verified (potential addresses there are put into the white_list when verified). And adversaries can push up to 250 new addresses there per Levin handshake.
rucknium: By "verified" I mean check that there is actually a reachable node at that address:port.
vtnerd: yeah Im liking the change more. that flipped logic to pull from graylist is funky. wish we had someone to describe the reasoning (assuming there was any)
vtnerd: presumably it was done to prevent concentration amongst a small number of peers, but the other logic to prefer recently connected suggests against that
rucknium: When rburnner and I looked at it last year, it was interesting to me that the logic pulled in two different directions with respect to "recent" peers. I thought maybe it was OK like it is, because it was "balanced".
rucknium: But in the end it was vulnerable.
rucknium: I'm going to ping boog900:monero.social in case he wants to comment.
rucknium: My next step is to make a PR with the patch and the analysis I explained here. The full patch will remove dead logic, too.
vtnerd: the logic appears changed in this patch anyway https://github.com/monero-project/monero/commit/b750fb27b0f20e9443827732b69a504a76036430#diff-85f0577b849d28c11a899cb863aec3df1d946e0bb214a623deef05928271fef6
vtnerd: I believe the original logic was to attempt one whitelist, then grey each time
vtnerd: whereas this add the while loop
vtnerd: the original code may have been worse actually
https://libera.monerologs.net/monero-research-lab/20260930#c711528

quoting
nevent1q…0vqm
Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!": https://arxiv.org/pdf/2609.10260
nevent1qqststnsjl4xtxtmuttamd34fg7umxrclwyqmzeutlsqm6j7y6t0rggrg663f

jeffro256: Beta v3 is released! jberman: you can download the ...

2026-10-01T03:24:00Z

jeffro256: Beta v3 is released!
jberman: you can download the software to participate here: https://github.com/seraphis-migration/monero/releases/
jeffro256: v17 fork is at height 3102800
gingeropolous: im trying to organize data capture and measurement effort
https://github.com/seraphis-migration/monero/issues/495 - please comment
rucknium: How much is the bot borrowing from my https://github.com/Rucknium/monerod-monitor ? :D
gingeropolous: i didn't point it at it. But that just seems to be for an individual's node?
rucknium: Isn't your prpoposal also for an individual's node?
gingeropolous: yes, but it will push data to a central data collector, and log the generation of txs from the spam generator (on the MRC), etc.
rucknium: Anyway, not very important. I notice the issue says that the data will be in an R-compatible format. That's good. Well, most data formats are R-compatible because there are packages to read everything.
rucknium: The UI part of my monitor is very slow. I'm not happy about that.
https://libera.monerologs.net/monero-research-lab/20260930#c711509

quoting
nevent1q…v4ak
FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
Version 3 launch checklist: https://github.com/seraphis-migration/monero/pull/415
nevent1qqs8074l6fy5mr9jxt3p0g7lta84f80s3qwfzpzt7vzhktdh3q3m23szgvmd6

jberman opened all Phase 3 integration-audit PRs; the final ...

2026-10-01T03:14:34Z

jberman opened all Phase 3 integration-audit PRs; the final consensus-verification PR is https://github.com/monero-project/monero/pull/11440. Phase 2 integration PRs are already merged.
He said reviews and merges can proceed in parallel with audits, and next will draft an RFQ for audit phases 2 and 3 as proposed last week by sgp_. The RFQ is not live yet; sgp_ sends scope emails to firms, quotes are discussed in MRL, and a candidate is chosen.
Firms can subscribe at https://listmonk.magicgrants.org/subscription/form.
On research audits: Least Authority privately shared a final helioselene report (still under internal review) and is slated for the 2nd-round circuit/gadgets audit and 1st-round fcmp-plus-plus lib audit.
UkoeHB is rebasing FCMP++ & Carrot multisig onto the latest fcmp++-stage branch. jberman called upstream merge the likely biggest bottleneck and requested reviews on https://github.com/monero-project/monero/pull/11440.

jberman: On upstream FCMP++ integration, repeating from above I opened all PR's for Phase 3 of the FCMP++ integration audit which includes all code necessary to verify FCMP++ txs at consensus to prevent inflation. Here is the final consensus verification integration PR: https://github.com/monero-project/monero/pull/11440
Next I'll write up a draft to include in a request for quotes on audit phases 2 & 3, as proposed by sgp_:monero.social last week
jeffro256: Is tobtoht back yet?
Still waiting on mx25519 issues to resolve as a prereq to carrot_core.
jberman: To be clear, phase 2 integration PR's have already been merged. Phase 3 PR's are now open for review as linked above. It's my opinion we can proceed with reviews (and merges) today in parallel to the audits
MarkoPohlo: Is the request for quotes process (audit phases 2 & 3) currently live and if so, how does participation in that normally look like?
vtnerd: I think the mx25519 pr is ready, was there something else?
jeffro256: Licensing
jberman: MarkoPohlo: It's not currently live. We ( sgp_:monero.social ) sends out emails to different firms with information on scope and requests a quote, then we discuss quotes received in here and settle on a candidate
sgp_: MarkoPohlo: no it is not yet live. Sign up for the RFQ newsletter here to be notified: https://listmonk.magicgrants.org/subscription/form
MarkoPohlo: Appreciate the explanation, we (Runtime Verification) would love the chance to participate in the process.
sgp_: You are welcome to, and I am excited to receive your proposal
jberman: On Research audit items: Least Authority privately shared their final report on helioselene (still looking it over internally), and is also the firm we're slated to kick off the 2nd round of audits on the cirtcuit and gadgets impl & 1st round on fcmp-plus-plus lib
jberman: UkoeHB is rebasing the FCMP++ & Carrot multisig impl onto the latest fcmp++-stage development branch. That's a major feature item on the TODO list
jberman: I'd say our likely biggest bottleneck going forward is getting code merged upstream. So, requesting reviews on the FCMP++ integration PR's linked here to get that going: https://github.com/monero-project/monero/pull/11440
jberman: that's all from me
rucknium: Thank you. Anything else on this topic from anyone?
https://libera.monerologs.net/monero-research-lab/20260930#c711485

quoting
nevent1q…j9el
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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsf6dtfjynr57feus7amyqrtmacwk6gf3ftrv8kwze3jqmwf0qwz3sxcngzn

Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully ...

2026-09-30T03:48:16Z

In reply to nevent1q…vht8
_________________________

Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!": https://arxiv.org/pdf/2609.10260
nevent1qqststnsjl4xtxtmuttamd34fg7umxrclwyqmzeutlsqm6j7y6t0rggrg663f

Relative locks with FCMP++: ...

2026-09-30T03:46:50Z

In reply to nevent1q…z0r2
_________________________

Relative locks with FCMP++: https://github.com/monero-project/research-lab/issues/161
nevent1qqs8k824qmdk2lgk3f5n6ame8kx22jhh2m342clmj9m762tlcvzxljc23jshq

FCMP beta stressnet: ...

2026-09-30T03:42:16Z

In reply to nevent1q…x2m7
_________________________

FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
Version 3 launch checklist: https://github.com/seraphis-migration/monero/pull/415
nevent1qqs8074l6fy5mr9jxt3p0g7lta84f80s3qwfzpzt7vzhktdh3q3m23szgvmd6

FCMP++ to-do list status. Programming tasks: ...

2026-09-30T03:40:36Z

In reply to nevent1q…st4a
_________________________

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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsf6dtfjynr57feus7amyqrtmacwk6gf3ftrv8kwze3jqmwf0qwz3sxcngzn

Monero Research Lab Meeting - Wed 30 September 2026, 17:00 ...

2026-09-30T03:38:56Z

Monero Research Lab Meeting - Wed 30 September 2026, 17:00 UTChttps://github.com/monero-project/meta/issues/1466

The Road to Divisors in #Monero What do you do when experts ...

2026-09-29T15:41:30Z

The Road to Divisors in #Monero
What do you do when experts disagree? Three independent reviews, two years of work, and now a machine-checked proof.
Learn more ⬇️
https://magicgrants.org/2026/09/29/Divisors-in-Monero

zkSecurity announced that they have formally verified the ...

2026-09-29T15:39:57Z

zkSecurity announced that they have formally verified the techniques of Liam Eagen's https://eprint.iacr.org/2022/596 in Lean 4, using only the standard axioms:
https://magicgrants.org/2026/09/29/Divisors-in-Monero
https://github.com/zksecurity/eagen-divisor-formalization

X thread: https://x.com/zksecurityXYZ/status/2104953772669808866
"These techniques allows the construction of *extremely* cheap proofs of inner products relations on elliptic curves inside circuits; as long as linear combinations are free.
However, it relies on some relatively involved/subtle algebraic geometry and both the analysis and the implementation are potentially easy to get wrong.
We think that formal verification can solve this.
Because we can verify both the protocol and then tie it back to verified Clean (https://clean.zksecurity.xyz) circuits implementing the technique.
So since spring, we spent time, on our own initiative, to formalizing this. It was done by guiding AI through the techniques in https://blog.zksecurity.xyz/posts/divisor-notes/ , as well as carefully writing and reviewing the central theorem statements.
The most interesting of which is soundness of the Merlin-Arthur protocol at the heart of the technique ("ma_soundness" in the formalization).
For more details on the protocol itself, see our original report: https://blog.zksecurity.xyz/posts/divisor-notes/divisor-techniques.pdf";

rucknium and gingeropolous reproduced the Nyx eclipse in ...

2026-09-24T15:39:21Z

rucknium and gingeropolous reproduced the Nyx eclipse in monerosim; countermeasures are under test. Attack needs ~1,000 IPs, each in its own /24. No mainnet Nyx signature in recent scans. Detectability: attacker must stuff reachable white lists, biasing honest peerlists. Moros poisons seed-node peerlists to eclipse newborns; authors did that on mainnet seed nodes around late Nov–mid Dec 2025, coinciding with scanner trouble. rucknium and rbrunner said that was not appropriate; authors could have run private seeds. Paper appendix says real new nodes would eventually escape. Tor safety board cited as contrast: https://research.torproject.org/safetyboard
Countermeasures being coded: (1) white list 1,000 → 10,000; (2) try white list before gray list for new connections; (3) uniform white-list selection instead of most-recently-seen. #1 should not worsen this attack and was suggested twice by the same group, including https://moneroresearch.info/248 (NDSS 2025). Gray list still feeds reachability probes into the white list. Goal of a larger white list: if it exceeds reachable IPs, honest peers cannot be evicted. vtnerd warned recency bias helps after restart with dead ip:port pairs; rucknium said restarts use the anchor list first and is not committed to uniform selection. jpk68 asked for a written peer-handling spec; rucknium agreed and said Chesterton’s-fence deference to original CryptoNote P2P should end. White-list size 1,000 dates to the oldest codebase commit. ack-j posted repo-wide git-blame results:

rucknium: 8. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260)
rucknium: gingeropolous and I have been working on reproducing the attack in monerosim. It looks like the attack is reproducible. I have been testing countermeasures.
vtnerd: doesn’t this require lots of /24 addresses, or am I missing something … ?
rucknium: vtnerd: Yes it does. Well, about 1,000 IP addresses, each in its own /24
rucknium: I think it's possible to make this attack less costly, for little cost to monerod
rbrunner: That's not nothing ...
rucknium: I mean, make the attack more costly
vtnerd: yes, understood.
rbrunner: Nice that it's possible now to actually test it, no?
rucknium: I am pretty sure that the attack would be detectable through a network scan of mainnet. I looked through a couple of recent network scans and I didn't see any evidence of the attack being attempted. I mean the Nyx attack of eclipsing an established unreachable node. The Moros attack is different, which I will get to later.
rucknium: rbrunner: Yes. Our ability to test this was the result of several past decisions made in years past.
rucknium: Mainly, gingeropolous adapting Shadow for #Monero, creating monerosim. And the hardware purchases of 1TB RAM. Thank you, CCS donors!
jpk68: rucknium: Do you think it would be eventually worthwhile to have a written document outlining the specific required logic for handling peers and such, in order to protect against faulty implementations and ensure reference implementation behaviour remains correct?
rucknium: jpk68: Definitely.
rucknium: A lot of the logic was inherited from Monero's ancient Cryptonote ancestors. The ancestors speak no longer (or at least they don't identify themselves).
ack-j: It would be interesting to scan the git history of monerod to see which lines of code are the oldest without being updated
rucknium: We don't know the reason things are written they way they are. Maybe it was to maximize connectivity with honest nodes but they did not fully explore what an adversary could do.
jpk68: I mean, even with some remaining similarities, this research could probably be useful for projects like Zano and MobileCoin (if it still exists...) as well
rucknium: ack-j: One of the big ones is white list size 1,000, which is with the oldest commit of the original codebase.
rucknium: The reason that I think the attack is detectable on mainnet is that the attacker needs to stuff reachable node white lists with their own IP addresses, pushing out honest IP addresses. In that case, the peerlists the honest nodes share would be biased. I performed some chi-squared tests and found no obvious bias.
rucknium: I think it's time to stop using the "Chesterton's Fence" reasoning to give the benefit of the doubt to the original cryptonote network code.
rucknium: rbrunner and I puzzled over some of that code when we added the /24 deduplication rule.
jpk68: rucknium: As in, stop questioning it, or begin questioning it? I assume you mean the latter
rucknium: Begin questioning it.
rucknium: The second attack in the paper, Moros, requires the attacker to stuff the peerlists of seed nodes to eclipse brand new nodes.
rbrunner: Well, not knowing why a fence is there is compatible with seeing that today it's not good anymore
rucknium: The research team actually did that to mainnet seed nodes.
ack-j:

ack-j: Results from git blame
ack-j: Over every line in the monero repo
rucknium: They said they did it in the paper. And I think I see some evidence of their poisoning in late November to mid December 2025, in the network scan data.
rbrunner: Hmm. Is that still friendly, to be expected from people who write papers?
rucknium: Which was coincidentally around the time that I though my network scanner code was failing to do its job. It would make sense that my scanner was finding it hard to scan if the seed nodes were poisoned.
rucknium: rbrunner: IMHO, they should not have done that
rucknium: They could have set up their own "seed nodes", even on mainnet, and modified their nodes' code to point to those seed nodes. You could have the same effect IMHO. I mean, test the theory without messing with mainnet real seed nodes.
rucknium: They say in the appendix that actual new Monero nodes would have eventually gotten out of the eclipse.
rbrunner: Did not fully read the paper. Is that "Moros" attack alone able to achieve something dangerous?
rucknium: Tor has a research safety board for this kind of thing by the way: https://research.torproject.org/safetyboard
rucknium: rbrunner: It could eclipse newborn nodes from the start. Not as widespread of a problem as eclipsing all the established unreachable nodes.
rbrunner: I see
rucknium: The countermeasures I am testing are 1) Expand the whitelist size from 1,000 to 10,000. 2) Try to add a new conenction from the white list first instead of the gray list. 3) Select new connections uniformly from the white list instead of biasing toward the most recently seen ones.
rucknium: Those countermeasures are the intersection of what I think may be effective and what I can actually code myself in C++
rucknium: :D
rbrunner: Sounds interesting, where it's probably not immediately clear for all 3 whether it's a good idea or makes things actually worse
rucknium: I am pretty sure #1 cannot make things worse, at least with this specific attack.
rbrunner: Is the gray list still good for something with 2) implemented?
ofrnxmr: can the white list even get that big without constantly evictinf and switching peers?
rucknium: Actually this research group has suggested to Monero twice to increase the white list size limit.
rucknium: rbrunner: Yes because there is a housekeeping method that tests gray list peers for reachability, then puts them in the white list if they are reachable. But it doesn't add those as an actual connection unless it is later selected from the white list as a new connection.
rucknium: The purpose of increasing the white list size is to prevent manipulative adversaries from pushing out honest peers from that list. If the list is larger than the total reachable IP addresses, the honest peers cannot be pushed out.
vtnerd: one problem I see is that if you restart monerod, then the recently connected helps with dead ip/port pairs
rucknium: This is the paper last year where they suggested increasing the white list size: https://moneroresearch.info/248 Shi, R., Peng, Z., Lan, L., Ge, Y., Liu, P., & Wang, Q., et al. 2025, February 24–28, Eclipse Attacks on Monero’s Peer-to-Peer Network. Unpublished paper presented at Network and Distributed System Security (NDSS) Symposium 2025.
vtnerd: *selecting/bias from the recently connected
rucknium: vtnerd: IIRC, on a restart you select from the anchorlist first.
rucknium: I am not committed to uniform selection from the white list. Just testing things now.
https://libera.monerologs.net/monero-research-lab/20260923#c710195

quoting
nevent1q…8una
Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!": https://arxiv.org/pdf/2609.10260
nevent1qqststnsjl4xtxtmuttamd34fg7umxrclwyqmzeutlsqm6j7y6t0rggrg663f

MAGIC commissioned Dr. Wang after an earlier CCS review found a ...

2026-09-24T15:28:39Z

MAGIC commissioned Dr. Wang after an earlier CCS review found a proof gap but treated the theorem as fine in practice without a rigorous write-up. Wang/Liu supplied a rigorous repair. ack-j said MAGIC is happy with Wang’s group.

sgp_: I don't have much to add on this section, besides "read the post and the review"
sgp_: The original work that Dr. Wang was hired for, on more efficient range proofs, is still coming later this year
sgp_: If time permits, I hope to do a Plaintext podcast on this topic
ack-j: Needless to say, magic has been very happy with the work of Dr Wang and his colleagues
rucknium: Is this summary correct?: BP+ paper was written. Through CCS, a team was hired to review it. They found a problem with the original proof, but deemed the actual theorem to be correct. However, that team didn't write a rigorous-enough proof of the final result. Then Dr. Wang looked at it and noticed the lacking rigor. They wrote a rigorous proof that fully repaired the original BP+ proof.
rucknium: BP+ was a very modest reduction to the proof size IIRC. Makes one wonder about the risk-reward balance on that one.
sgp_: That is largely correct. It's not that they wrote a bad proof for the initial review, it's that they said it looked good without demonstrating so
sgp_: "here's an issue, but it is fine in practice", basically
sgp_: which, technically, was true, but not supported at the time
rucknium: Thanks for organizing the most recent review, MAGIC
https://libera.monerologs.net/monero-research-lab/20260923#c710173

quoting
nevent1q…dy9a
Bulletproofs+ Aggregate Range Proof Issue Identified and Resolved: https://magicgrants.org/2026/09/22/Bulletproofs+-Report
nevent1qqsdzzezk34vzycntcd0wvtnzpqn0nsv0nyvj3qvtm2dcffl5ma562cmcs365

Code is ready. Target fork Monday 5 Oct 2026; binaries expected ...

2026-09-24T15:23:00Z

Code is ready. Target fork Monday 5 Oct 2026; binaries expected within a day. jeffro256 proposed a 10 MB initial penalty-free zone (20 MB blocks if full penalty paid) to skip warm-up and resume prior spam volumes; leftover bugs should match the earlier raise to 625K. RandomX v2 will be in v3. sech1 will ship P2Pool v5.0-beta after pulling Carrot K^j_v rebind (https://github.com/seraphis-migration/monero/pull/456), generator T (https://github.com/monero-project/monero/pull/10963), and carrot_convergence tests.

jberman: We can schedule beta v3 launch during this meeting. The code is now ready to go. Can see all the items we knocked out in that checklist there
jberman: I think it would be nice to have some testing done on current testnet before the fork as well, but caution that we don't want people stress testing current testnet
jberman: Another test that would be good to have people check is migrating a testnet wallet from current testnet to a fork compatible wallet (i.e. create and use a wallet now on current testnet, and then open that wallet with the new beta v3 software)
jberman: So with that in mind, how about we target Monday Oct 5th for the fork to give people some time to get set up again with current testnet and with the new beta v3 software before the fork. We should be able to get binaries released within the next day
jeffro256: We also wanted to discuss the initial penalty free zone parameter. Is 10MB okay? Would allow for 20MB blocks at HF if full penalty is paid. A 10MB param would help us skip the initial "warm-up" phase and get back to spamming at volumes similar to when we left off
rucknium: Oct 5th sounds good to me
sech1: If RandomX v2 is merged into the stage branch, then version 3 will have it too, right?
jeffro256: Yes
sech1: P2Pool's v5 branch (FCMP++/Carrot/RandomX v2 compatible) is ready for testing then
sech1: Oct 5th sounds good
rucknium: jeffro256: Have all the bugs have been fixed with that? (the hard way?)
sech1: I'll have P2Pool v5.0-beta release before that
jeffro256: sech1: Does that branch have this change in it?: https://github.com/seraphis-migration/monero/pull/456.
jeffro256: Or at least uses the carrot_core code that is up-to-date with fcmp++-stage?
jeffro256: If using an up-to-date carrot_core, then nothing else needs to be done
sech1: No, it doesn't
sech1: I'll go through all the changes and update P2Pool side
sech1: It doesn't use carrot_core code. All math is tailor-made for P2Pool
jeffro256: IIRC that's the only backwards-incompatible change to Carrot since beta v2
sech1: yeah, if it was merged 15 hours ago, P2Pool definitely doesn't have it yet
jeffro256: Changes are posted to the spec repo, the tweak is very simple on the sender side
jeffro256: Does p2pool implement scanning code?
sech1: No
sech1: It does "scanning" by reconstructing the sender side for each output. But it's only used to display "this wallet got this much XMR in this block" message
jeffro256: Ok sweet, then hopefully it shouldn't be too hard. In the d_e derivation, simply include K^j_v right after K^j_s
sech1: sounds simple enough
jeffro256: There was also the T generator change: https://github.com/monero-project/monero/pull/10963, so make sure that that value matches upstream
jeffro256: The T value was also updated in the spec
jeffro256: I'm sure you know, but there's always the carrot_convergence tests to verify impls against: https://github.com/seraphis-migration/monero/blob/fcmp%2B%2B-stage/tests/unit_tests/carrot_convergence.cpp
jeffro256: rucknium: It should be the same bugs that we fixed increaseing it to 625
jeffro256: 625K
sech1: jeffor256 yes, I know about generator T, and I did integrate the convergence tests
https://libera.monerologs.net/monero-research-lab/20260923#c710138

quoting
nevent1q…26wd
FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
Version 3 launch checklist: https://github.com/seraphis-migration/monero/pull/415
nevent1qqs0hp0k0hpt9cnw7cygs39jne5emw8w2aqnqjkht9kd09t6zdgj6uqsjcndu

Helioselene audit (Least Authority) is near release; last week a ...

2026-09-24T15:17:27Z

Helioselene audit (Least Authority) is near release; last week a candidate was chosen for a second-round circuit/gadgets + fcmp-plus-plus lib audit. Luke patched a Helios/Selene “best practice” finding: https://github.com/monero-oxide/monero-oxide/commit/77788c368145127f2dde2ac3e2ddce919f3ddd01. Integration cleared hot-cold, unique curve-tree roots (https://github.com/seraphis-migration/monero/pull/462), and RandomX V2 on staging. First 2/3 Audit Phase 2 PRs are merged; open upstream PR is curve-tree building, https://github.com/monero-project/monero/pull/10724. jberman will draft Phase 2 RFQs in 1–2 days; upstream PRs should not wait on audits. sgp_ asked about quoting Phase 2+3 together; jberman will prep Phase 3 PRs to judge that. Phase 2 is not large.

jeffro256: Sorry I haven't updated that chart in a few weeks
jberman: On Research items: helioselene audit is nearing release, and we settled on a candidate in last week's meeting for the audit of circuit + gadgets (second round of review) and fcmp-plus-plus lib
jeffro256: I assume tobtoht isn't here?
sgp_: Luke made a patch to address one finding from the LA Helios/Selene review (which my understanding is more of a "best practice" recommendation than a direct risk as implemented). That final report is expected in the coming days: https://github.com/monero-oxide/monero-oxide/commit/77788c368145127f2dde2ac3e2ddce919f3ddd01
jpk68: Potentially a dumb question, but is the identity of the firm authoring the Helioselene audit publicly known yet?
sgp_: Least Authority
rbrunner: Oh, that's the name of a company, not some security policy / system / approach / whatever
jberman: On integration, we knocked off a whole list of items that have been on the to-do list: hot-cold integration, guarantee every curve tree root is unique ( https://github.com/seraphis-migration/monero/pull/462 ), we merged RandomX V2 into our staging branch and those changes LGTM though there is still the more minor question of dealing with # of txs in the header, @jeffro256:monero.social's implementation of @tevador 's suggestion to improve the privacy profile of an eventual theoretical PQ turnstile ( https://github.com/seraphis-migration/monero/pull/456 ), maybe more
sgp_: rbrunner: correct
sgp_: jberman: yay preparing for worst case scenarios
jberman: On upstream FCMP++ integration PR's: first 2/3 PR's from the Audit Phase 2 are merged, latest outstanding open PR is the curve tree building code which is a significant PR: https://github.com/monero-project/monero/pull/10724
jberman: I plan to prepare a request for quotes for Audit Phase 2 within the next day or 2, so sgp_ can start contacting firms there and we can get that rolling
jberman: Again, I don't think upstream PR's need to be blocked by pending audits
sgp_: jberman: would it potentially make sense to get quotes for 2+3 together, or is that not feasible?
jberman: It might
jberman: I'll work on preparing Phase 3 PR's next in that case to get a better a read
sgp_: Sounds good
jberman: This Phase 2 isn't too big
jberman: nothing from me
https://libera.monerologs.net/monero-research-lab/20260923#c710114

quoting
nevent1q…n496
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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsw9cyy46apuzs9s0p9z90w7l67r9w86v07aa8adsns8u37wpxnqhsywdt4n

Kirschner (2026) “An Analysis of Monero’s Network Topology” ...

2026-09-24T15:11:37Z

Kirschner (2026) “An Analysis of Monero’s Network Topology” (https://ieeexplore.ieee.org/abstract/document/11676613)
jkirsch10 presented a ~2-year-old passive crawl: discover active nodes via the #Monero protocol, then measure network-level structure. Main claim is edge concentration on a small set of nodes that is not community-specific, so routing attacks could matter; he said that impact should be treated skeptically and the experiments should be rerun. jeffro256 asked about /24-as-one-choice outgoing selection; jkirsch10 said only a small effect (about four /24 prefixes in the concentration result). He has not studied other coin networks. rucknium flagged a claim that some nodes advertised peer lists larger than the 1,000 white-list cap; boog900 said current code drops oversized lists, with 250 the max add per message and 1,000 the full list. LinkingLion has been active since ~2018 (selsta cited https://github.com/monero-project/monero/pull/7073). Interpretation split: paper “edges” are white-list membership, not live connections. jkirsch10 reported ~24% suspected spy nodes accounting for 67% of those white-list edges and embedding in everyone else’s lists; spies only advertised other spies. rucknium pointed to https://xmrnetscan.redteam.cash/ and Gao et al. 2025 (https://moneroresearch.info/278). Author called the paper limited but useful as experiment fodder.rucknium: 3. Kirschner (2026) “An Analysis of Monero’s Network Topology” (https://ieeexplore.ieee.org/abstract/document/11676613)
rucknium: Thank you for joining us. Do you want to briefly explain your paper?
jkirsch10: Hi yes thank you
jkirsch10: The goal of the paper was to characterize some basic network-level (as opposed to node-level) features of the network. The methodology aimed to be relatively passive, i.e. using monero protocol itself. The primary goal is discovering as many active nodes as possible. Then some very basic analysis is done regarding network concentration to preliminarily characterize the relative impact on e.g. mining of there were to be a routing attack. Overall the paper is very basic and warrants further research. Note that some language in the paper including some language I am using now is more appropriate for traditional networks rather than p2p network.
jkirsch10: The primary characteristic finding of the paper is the high concentration of proportion of netwrok edges in a relatively small proportion of network nodes, and that these edges are not network community specific. Thus routing attack could have big effect. Again without further analysis this finding or rather its impact warrants skepticism
rucknium: Thanks. When did you finish writing this paper?
jkirsch10: Yes very important. In terms of the numbers presented, (due to lengthy research/publishing process) the experiments in the paper are 2 years old and experiments should be run again to get updated figures
rucknium: That makes sense. I noticed that the most recent reference was 2022. You have some fact that are out of date.
rucknium: For example, you said that the default number of outbound connections is 8. It was raised to 12 in 2020: https://github.com/monero-project/monero/commit/c67fa324965268cd1c01cbcb513038e7344f35d1
jkirsch10: Agreed and thus basic protocol info given to reader are old
jkirsch10: yes exactly
jeffro256: Some big changes were made to outgoing connection selection to avoid spy node centralization. Specifically, it weights all IPs in a /24 subnet as "one choice" instead of N choices. Do you think that this would make a large impact to the findings?
rucknium: And there is this paper from 2025 that is very relevant: https://moneroresearch.info/278 Gao, Y., Zhang, Y., Piškorec, M., & Tessone, C. J. (2025). Monero Peer-to-peer Network Topology Analysis.
jkirsch10: jeffro256 It would make some impact on the findings although not a large one. For example main finding regarding node-edge concentration included a few /24 prefixes but not many. I don't have the exact number on hand, i think 4
ack-j: jkirsch10: have you analyzed other decentralized cryptocurrency networks in the past or since this paper?
jkirsch10: No I have not
rucknium: I don't agree with some of your interpretations of the data in here, but I will try not to eat up time here with that. I was surprised that you said "These nodes provide a peer list to other nodes that is larger than the maximum white list size of 1,000." That's interesting. I haven't noticed that in my network scans, but I have not checked that closely yet.
jeffro256: I wonder if LinkingLion was active in 2022... They were over 50% of reachable public nodes at some point, but IDK about in 2022
boog900: rucknium: I think that would get the peer dropped IIRC
jkirsch10: I completely admit that some of the interpretations of the data may be up to debate as I am certainly not an expert. Yes that was a main interesting finding and again although sending such a large peer list was not part of the protocol at the time perhaps maybe there have been protocol changes since the paper that either intentionally or "accidentally" prevent such "abuse"
boog900: https://github.com/monero-project/monero/blob/d02c7c57a7b9e9ce0eead684a48345c6f48fea81/src/p2p/net_node.inl#L2349
boog900: 250 is the max
rbrunner: So 1000 for the whole list, and adding 250 max in a single go?
jkirsch10: Ah, yes. At the time I did indeed passively form peer connections with them. Any node in the paper that was on any peer list yet I wasn't able to connect to was not included in the analsysis
jkirsch10: Sorry. i should say any node that was discovered, not "in the paper", if i wasn't able to connect, it is not in the paper and not in the data
boog900: rbrunner: yeah
rucknium: jkirsch10: Here is data from my network scanner, by the way: https://xmrnetscan.redteam.cash/
rucknium: You say in the paper that no one except MoneroHash monitors the network (and MoneroHash misses a lot of nodes). Now I've filled that gap :)
jkirsch10: What happened in June there? The big drop then coming back higher than before the drop... change in scanning?
rucknium: I use a dedicated scanner written in rust (mostly by boog900 ) that takes less than 24 hours to crawl the network. I mean, get all reachable peers.
rucknium: jkirsch10: I think it's a spy network going offline, then coming back.
rucknium: But they don't have the very identifiable spy node fingerprint. So they aren't labeled as such.
jkirsch10: Curious what is your criteria for determining that all reachable peers have been found, that is something that is assumed in my paper, not formally defined. I guess any definition would assume a convergence criteria, idk
rucknium: Get peer list from each node and exhaust them.
rucknium: I mean, start with the seed nodes and branch out, gathering peer lists as I go.
rucknium: You were doing it more "manually", with actual monerod nodes connecting and disconnecting.
rucknium: And note that the webapp counts each IP address only once. There are some nodes on the same IP address, but different ports.
jkirsch10: Yes right exactly. Ok Cool. Your approach is much more sophisticated then mine. Perhaps as inspiration from the paper you will look at the edge characteristics between and among the suspected spy nodes and the rest of the nodes. My findings were pretty much that 24% of nodes were suspected spy nodes, they accounted for 67% of [... too long, see https://mrelay.p2pool.observer/e/5Ovbxq0LRE9oczVi ]
jkirsch10: Meaning the spies were highly effective in embedding themselves in white lists of all other nodes
rucknium: > Here when I say "connected" or "edge" i dont mean active open connection, i just mean on other nodes' white list so there is at least the potential for connection
rucknium: That's mostly where I differed with you in interpretation. It sounds like you paper says that the edge were current active connections, but the peer list includes a random subset of the 1000-peer white list, not the actual current connections.
rucknium: Yes. The spy nodes only emitted the IP addresses of other spy nodes when it shared their peer lists. A "normal node" would have a (roughly uniform) random set of all reachable nodes on the network.
jkirsch10: right exactly, the intention there is to refer to white list not active connections. I do beleive I call that out in the paper, what the intention is, but regardless the language is confusing and unless you read that caveat... even more confusing
rucknium: jkirsch10: We need to get to the rest of the meeting agenda, but I encourage you to stay for the last agenda item if you want, Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260)
jkirsch10: Great. Thank you for inviting me today. My personal opinion is the paper has many shortcomings. I hope it is somewhat useful to you - perhaps primarily for spurring ideas on what types of experiments to do or what to investigate next.
jeffro256: Thank you, jkirsch10
selsta: 19:23 <+br-m> jeffro256 I wonder if LinkingLion was active in 2022... <-- they have been active since like 2018. Here a PR from 2020 that was related to LinkingLion: https://github.com/monero-project/monero/pull/7073
https://libera.monerologs.net/monero-research-lab/20260923#c710031

quoting
nevent1q…dhdj
#Monero Research Lab Meeting - Wed 23 September 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1464

Bulletproofs+ Aggregate Range Proof Issue Identified and ...

2026-09-23T03:14:13Z

In reply to nevent1q…aav8
_________________________

Bulletproofs+ Aggregate Range Proof Issue Identified and Resolved: https://magicgrants.org/2026/09/22/Bulletproofs+-Report
nevent1qqsdzzezk34vzycntcd0wvtnzpqn0nsv0nyvj3qvtm2dcffl5ma562cmcs365

FCMP beta stressnet: ...

2026-09-23T03:12:04Z

In reply to nevent1q…yj8s
_________________________

FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
Version 3 launch checklist: https://github.com/seraphis-migration/monero/pull/415
nevent1qqs0hp0k0hpt9cnw7cygs39jne5emw8w2aqnqjkht9kd09t6zdgj6uqsjcndu

FCMP++ to-do list status. Programming tasks: ...

2026-09-23T03:10:19Z

In reply to nevent1q…6s0c
_________________________

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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsw9cyy46apuzs9s0p9z90w7l67r9w86v07aa8adsns8u37wpxnqhsywdt4n

#Monero Research Lab Meeting - Wed 23 September 2026, 17:00 UTC ...

2026-09-23T03:08:03Z

#Monero Research Lab Meeting - Wed 23 September 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1464

jberman: next item on my plate here is rebasing on top of master ...

2026-09-17T03:31:46Z

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
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 (koe) can also continue with getting multisig rebased on top of the latest as well (once we're back on master)
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 )
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: https://libera.monerologs.net/monero-research-lab/20260916#c708186-c708187
https://libera.monerologs.net/monero-research-lab/20260916#c708285

quoting
nevent1q…res7
FCMP beta stressnet Releases: https://github.com/seraphis-migration/monero/releases/
Version 3 launch checklist: https://github.com/seraphis-migration/monero/pull/415
nevent1qqspawm0hp8t4l3wtd30c6j8dnj053vn7n9t5us0zzjgnrg45lkrk8c3fs0y8

rucknium: I don't know if anything has changed with relative ...

2026-09-17T03:21:52Z

rucknium: I don't know if anything has changed with relative locks. IIRC, tevador and jberman 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++"
https://libera.monerologs.net/monero-research-lab/20260916#c708281

quoting
nevent1q…ugx6
Relative locks with FCMP++
https://github.com/monero-project/research-lab/issues/161
nevent1qqstk2t9tyvncpzel6ethl5654rd7ga32pdx4ved97r9kpsjgr0rtes3ptl64

Hot-cold is merged. jberman is rebasing FCMP++/Carrot on master ...

2026-09-17T03:12:21Z

Hot-cold is merged. jberman is rebasing FCMP++/Carrot on master for beta v3 (rollback for existing beta users, higher min penalty zone, minor beta PRs; possible Rust lib regression with kayabanerve). RandomX v2 PR https://github.com/monero-project/monero/pull/10038 discussed; not a beta-v3 blocker. Upstream PRs ready: https://github.com/monero-project/monero/pull/10361 https://github.com/monero-project/monero/pull/10362 https://github.com/monero-project/monero/pull/10724 (curve tree builder; Phase 2 complete). Licensing lib https://github.com/monero-project/monero/pull/11288. Multisig next major milestone. Code hoped ready for beta v3 by next week.

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 )
sech1: No plans to include RandomX v2 into beta v3?
jberman: Is that ready?
sech1: There is a PR to master branch
sech1: Which hasn't received approvals yet because it does some controversial changes on top of RandomX v2
sech1: 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
sech1: 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 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: https://github.com/monero-project/monero/pull/10361
jberman: https://github.com/monero-project/monero/pull/10362
jberman: https://github.com/monero-project/monero/pull/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: https://github.com/monero-project/monero/pull/11288. Any thoughts tevador or tobtoht about it in general?
jpk68: 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 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
https://libera.monerologs.net/monero-research-lab/20260916#c708181

quoting
nevent1q…7j3f
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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsqcf4e4c8fy3pyyv8dcpxh078q24afjxl7q5kdr8vufzq3h3l6ksq4xdjx7

FCMP beta stressnet Releases: ...

2026-09-16T00:18:21Z

In reply to nevent1q…t0ys
_________________________

FCMP beta stressnet Releases: https://github.com/seraphis-migration/monero/releases/
Version 3 launch checklist: https://github.com/seraphis-migration/monero/pull/415
nevent1qqspawm0hp8t4l3wtd30c6j8dnj053vn7n9t5us0zzjgnrg45lkrk8c3fs0y8

Relative locks with FCMP++ ...

2026-09-16T00:16:25Z

In reply to nevent1q…8h09
_________________________

Relative locks with FCMP++
https://github.com/monero-project/research-lab/issues/161
nevent1qqstk2t9tyvncpzel6ethl5654rd7ga32pdx4ved97r9kpsjgr0rtes3ptl64

Second FCMP++ circuit review: CCS approval.

2026-09-16T00:15:41Z

In reply to nevent1q…f4nr
_________________________

Second FCMP++ circuit review: CCS approval.

FCMP++ to-do list status. Programming tasks: ...

2026-09-16T00:14:13Z

In reply to nevent1q…9ltn
_________________________

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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsqcf4e4c8fy3pyyv8dcpxh078q24afjxl7q5kdr8vufzq3h3l6ksq4xdjx7

Tehrani & Tovanich (2026) "MoneroVis: Visual Analytics ...

2026-09-16T00:13:19Z

In reply to nevent1q…jd69
_________________________

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

Monero Research Lab Meeting - Wed 16 September 2026, 17:00 UTC ...

2026-09-16T00:08:37Z

Monero Research Lab Meeting - Wed 16 September 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1458

jberman: On research tasks: we're evaluating the quotes to ...

2026-09-09T20:02:18Z

jberman: On research tasks: we're evaluating the quotes to audit the circuit + gadgets impl + fcmp-plus-plus lib, we've received all quotes. Will have more on this next week
jberman: The hot/cold wallet PR I personally think is nearly complete (thank you to jeffro256 for the hard work there)
jberman: Making progress on upstream integration PR's with reviews
jberman: The hot/cold wallet PR is basically the next major milestone to keep an eye out for
sgp_: The goal is to make a decision during the next meeting, and I'll make sure that the info is shared in this channel on Monday. We received 7 quotes
https://libera.monerologs.net/monero-research-lab/20260909#c706661

quoting
nevent1q…808p
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 schedule Gantt chart: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
nevent1qqsralx7xlt83l0nmdq7q4v6ezgq9e3s92u5lwl95zsy99gxkvm4ggqau0fca