Nostr notes by MoneroResearchLab

rucknium: At the last #no-wallet-left-behind:monero.social ...

2026-11-05T04:23:38Z

rucknium: At the last #no-wallet-left-behind:monero.social meeting, ofrnxmr suggested my PR isn't as urgent because the latest simulations showed that a subnet-concentrated adversary can't perform the Nyx eclipse attack. And ofrnxmr is working on another solution. I don't care much which solution (or both) is merged, as long as it's merged before the next release version is tagged.
ofrnxmr: Would people prefer an all-in-one pr? Easier to understand why each design choice it made when all together, but there are also pieces that can go uostream on their own, which are easier to review
I dont mind doing it vtnerd style, where the all-in-one is open (like 8867), but pieces of it are split out to make review easier
rucknium: Doesn't make much difference to me, but your main audience would be the usual PR reviewers I assume.
https://libera.monerologs.net/monero-research-lab/20261104#c719056

quoting
nevent1q…cq02
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
nevent1qqstaehtw02ws9yweymqslwrza3f0d7r08maq239dqpes6haav7ezssjt0gzx

rucknium: I'm writing up my thoughts on open questions, ...

2026-11-05T04:20:26Z

rucknium: I'm writing up my thoughts on open questions, methodology, and future research direction for selfish mining and Share or Perish. I wanted to finish that task by now, but I didn't.
https://libera.monerologs.net/monero-research-lab/20261104#c719053

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

ofrnxmr: Ginger found an issue where ibd can stall if ltm lets ...

2026-11-05T04:18:58Z

ofrnxmr: Ginger found an issue where ibd can stall if ltm lets blocks get big after a lul
I have an elegant solution and 0xfffc will push soon
rucknium: ibd = Initial block download. ltm = long-term median block size. lul = lull.
https://libera.monerologs.net/monero-research-lab/20261104#c719039

quoting
nevent1q…4lfj
FCMP beta stressnet
https://github.com/seraphis-migration/monero/releases/
nevent1qqsfdjn2u7zalgye4p0fq8wm29cy22jrxrzg5sfdet2q57d93rvdnugwp6dy9

tevador: I reviewed the carrot PR and will be backporting the ...

2026-11-05T04:12:56Z

tevador: I reviewed the carrot PR and will be backporting the enote_type change to Jamtis.
https://libera.monerologs.net/monero-research-lab/20261104#c719010

quoting
nevent1q…53qc
get_tx_key/check_tx_key doxes sender in 2-out tx
https://github.com/monero-project/monero/issues/11586
nevent1qqs27dgh5h0zge562ta6jl5yefm2gpn50qrwfdm6ahvwd4n9gmkaz8sem3pn8

sgp_: We received 8 quotes on this matter, and we are reviewing ...

2026-11-05T04:11:08Z

sgp_: We received 8 quotes on this matter, and we are reviewing them now, with an expected push for a final decision during the next meeting
we are collecting more information about the reviewers' experiences now
We may recommend multiple auditors
https://libera.monerologs.net/monero-research-lab/20261104#c718979

quoting
nevent1q…e8yg
FCMP++ Phase 2 & 3 integration audits.

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

2026-11-04T14:48:16Z

In reply to nevent1q…2hxp
_________________________

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
nevent1qqstaehtw02ws9yweymqslwrza3f0d7r08maq239dqpes6haav7ezssjt0gzx

Share or Perish (selfish mining mitigation) ...

2026-11-04T14:46:47Z

In reply to nevent1q…wzdc
_________________________

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

FCMP beta stressnet ...

2026-11-04T14:45:56Z

In reply to nevent1q…hleh
_________________________

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

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

2026-11-04T14:45:03Z

In reply to nevent1q…wzla
_________________________

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
nevent1qqsdz8g8mv26htkw5re0jv3qkcetf2zfylm9fmaqjzwnxgav0xlkhegg5u2px

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

2026-11-04T14:43:40Z

In reply to nevent1q…t2qw
_________________________

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

FCMP++ Phase 2 & 3 integration audits.

2026-11-04T14:41:42Z

In reply to nevent1q…6j8m
_________________________

FCMP++ Phase 2 & 3 integration audits.

Monero Research Lab Meeting - Wed 04 November 2026, 17:00 UTC ...

2026-11-04T14:40:12Z

Monero Research Lab Meeting - Wed 04 November 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1484

rucknium presented simulation results for the Nyx eclipse attack ...

2026-10-29T17:53:44Z

rucknium presented simulation results for the Nyx eclipse attack under different patches and adversary strategies (separate /24s vs. 10 nodes per /24). His patch and ofrnxmr’s proposed changes perform roughly the same in the reviewed scenarios; ofrnxmr’s aims to handle more diverse strategies and includes bucketing, coarser deduplication, test-before-evict, and one outbound peer per netgroup. Images of results were shared. interestingband argued that any P2P without node weights is doomed, that whitelist changes are pointless, and that the correct approach is weighting nodes by hashrate/mining capability (non-miners connect via miners). Several participants pushed back: most nodes do not mine, a small miner could give an adversary an advantage, IPv4 scarcity currently provides a form of address limitation, and the proposed patch is a simple, practical defense against the specific Nyx cookbook attack rather than a comprehensive sybil solution. vtnerd supported the PR for that reason while noting residual issues without IPv4 scarcity. ofrnxmr described the concrete changes in the proposed series and noted they are not mutually exclusive with rucknium’s PR. rucknium listed possible paths (merge his PR, ofrnxmr’s, both, do nothing, or another solution). Discussion continued on list-size trade-offs, academic vs. practical approaches, and the need for a stop-gap while larger designs are explored.

rucknium: 7. 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).
rucknium: ofrnxmr: Do you want to discuss your proposed patches?
interestingband: p2p without any weight for nodes is doomed to fail by design, since all nodes are equal
interestingband: No idea why you are wasting time on white list change, it's pointless
plowsof: https://observer.monerodevs.org/
rucknium: interestingband: It fixes this specific attack. It's not pointless.
interestingband: There is an approach for p2p layer around nodes based on their weight which should be linked to their mining capabilites, all other nodes should be connected via them. Done.
interestingband: It doesn't fix any attack
interestingband: It's the same pointless approach as OSPEAD for decoy selection
rucknium: The simulation proves it fixes the Nyx attack.
interestingband: Your simulation is far from reality then, bcs monero should work with any anonymous network
jeffro256: Solution to problems with decentralized network: make it centralized. Nice. > interestingband: There is an approach for p2p layer around nodes based on their weight which should be linked to their mining capabilites, all other nodes should be connected via them. Done.
ofrnxmr: Not the same thing, but the 101s drop replacement i spoke about at last meeting (not implemented) would add some metric of weighting to whether peeer connections are dropped (instead of random selection). My series does test-before-evict as well
vtnerd: The change makes the attack harder, but as interestingband: points out its difficult to determine which nodes to select and why. The node weight isn't anymore centralized than the mining process
boog900: most nodes do not mine and a lot of miners don't run nodes
vtnerd: Otoh, most nodes arent mining so Im not sure how that would work
vtnerd: Yes
boog900: Chainalysis would just need to run a small miner to get an advantage over normal nodes
gingeropolous: i've tasked the bots with a similar thing, current progress here: https://github.com/Fountain5405/monerosim/blob/progress-brief/README.md
boog900: Or insert adversary
plowsof: is mining hash cheaper than renting ips? who knows
vtnerd: chainanalysis just needs to convince everyone to switch to ipv6 and it's the same issue
rucknium: My patch definitely isn't meant to solve all network sybil issues. It's just a simple, quick patch to prevent major network disruption if an adversary decides to use the Nyx cookbook soon.
vtnerd: Yes, I support the pr for that reason. Just pointing out that it's dicey without ipv4 scarcity
ofrnxmr: rucknium do you want to share the prelim results of the recent sims?
rucknium: Yes. Do you want to explain what you patches do?
syntheticbird: vtnerd: on the topic of expensive addressing and communication protocol against sybil attacks. monero p2p over meshtastic would be a blast for common people and a bummer for adversaries.
rucknium: your*
rucknium: meshtastic bandwidth is likely too little.
syntheticbird: true
boog900: Yeah our current network security relies on addresses being limited, I don't think PoW is the answer though
syntheticbird: sadness then
interestingband: jeffro256: You don't get it; it's about being clear about who is partiicpant and who is not, and assumptions of the decentralized "game". And centralized way is what you all are doing by relying on ipv4 subnet.
rucknium: Recently, 10% of Tor exit nodes were acting maliciously. Then the Tor project just removed them from the directory. Monero can't do that.
ofrnxmr: * Bucket whitelist into into 256 buckets of 16 > rucknium: Yes. Do you want to explain what you patches do?
ofrnxmr: * bucket graylist into 256 buckets of 32
ofrnxmr: * dedup by /16 instead of /24
ofrnxmr: * test peers before evicting from whitelist
ofrnxmr: * one outbound peer per netgroup (IPv4 /16, IPv6 /32)[... more lines follow, see https://mrelay.p2pool.observer/e/nMCU6rgLd3BQR2l4 ]
rucknium: (outbound-adversaries-unreachable-status-quo-rucknium-ofrnxmr.png)
rucknium: ^ Here the Nyx attack eclipse results. The first two you've seen before. The bottom one is ofrnxmr 's patch.
interestingband: I didn't specify anywhere any assumption about underlaying network cleanet, tor, i2p. The approach with explicit weight linked to hashrate works with any network.
rucknium: It's stochastic, so just one run with one unreachable node doesn't show the large-sample average.
ofrnxmr: rucknium: This is if the attacker has each node in a separate /24
rucknium: Yes
ofrnxmr: Results look different if we concentrate the nodes, and likely different still if the ratio of goodto bad is less in our favor
rucknium: Now, when the attacker has 10 nodes in each /24. (Well, not "each" /24. But 10 per /24. Same number of adversary nodes total (1000) )
rucknium: (outbound-adversaries-unreachable-status-quo-rucknium-ofrnxmr-10per.png)
rucknium: In this scenario, even the unpatched node does OK after a while because it has rbrunner7 's subnet deduplication logic.
interestingband: jeffro256: And alternative p2p layer can be active in parallel with what is active atm, with explicit share of resources between them. This way you get benefits of both at the cost of 1/N resource per each channel of communication. LOL
rucknium: I'd say with the scenarios we have reviewed, my patch and ofrnxmr 's patch perform roughly the same. But ofrnxmr 's patch intends to handle more diverse adversary strategies, AFAIK.
interestingband: What are the assumptions of your model for simulation, and what is proven in your simulation ? or it's just statistics for different strategies ?
rucknium: It is reassuring that an adversary really needs to have IP addresses in separate subnets to perform the attack. Thanks to gingeropolous for helping patch a bug in monerosim to allow us to test the 10per-subnet scenario.
rucknium: interestingband: I explain that in the PR description: https://github.com/monero-project/monero/pull/11527
rucknium: I assume that the adversary is carrying out the Shi et al. (2026) Nyx eclipse attack. There are other possible attacks, of course, that I don't model in the simulation.
interestingband: "TL;DR: An adversary with 1,000 or more IP addresses under its control ..." this part is solved with p2p based on weight linked to hashrate
interestingband: and then miners has weight, non miners has to rely on some miners or be a miner
interestingband: done
interestingband: whole PR can be wiped
gingeropolous: for a well-funded adversary hashrate isn't as expensive as we'd want it to be. trust me im a believer in PoW solves all the things but ....
rucknium: I solve it in fewer lines.
interestingband: Nah, it's the only mechanism to protect network and consensus: contribute to hashrate
interestingband: or rely on someone who does
boog900: > or rely on someone
interestingband: it's pointless to have p2p network disconnected from consensus
rucknium: Possible paths I see are: 1) My PR is reviewed and merged. 2) ofrnxmr make a PR and gets it reviewed and merged. 3) combination of both. 4) Do nothing. 5) Some other solution is developed.
interestingband: 5
sgp_: There are clearly downsides to prioritize by hashrate lol. But if you really want to propose this idea then write it up instead of interrupting
interestingband: and all prev options are not an option at all since they are analysed in the context of all monero components
ofrnxmr: rucknium: Ours arent mutually exclusive, mine can easily revert some of the changes from yours if mine is to be accepted later
interestingband: sgp_: I will
ofrnxmr: its much more lines than yours, of course, since it solves multiole issues that can arguably land on their own
interestingband: sgp_: And I'm not just interrupting, I've already said how to implement it so that both ways can coexist at the same time in backward compatible way
rucknium: vtnerd: I welcome you to review my PR on GitHub: https://github.com/monero-project/monero/pull/11527
ofrnxmr: I mean, monero doesnt typically like when you do 20 things in a single pr, so i might just start upstreaming certain commits that fix actual bugs, or fix bad behavior
rucknium: Anything else on this item for now?
interestingband: rucknium: What are the downsides of bigger lists ? Why not have it bigger or smaller ?
interestingband: "The defense scenario simulation increased the white_list size limit from 1,000 to 10,000. The limit was set arbitrarily. To be effective, the value in the simulation just needed to exceed the total count of the sum of honest and adversary nodes." So that constant is just a number to "fix" one attack scenario in your simulation, without validation of all other use cases or even proving anything at all ?
rucknium: Bigger list would mean slower performance in routines that operate on the list.
interestingband: Basically blind bit flip
interestingband: How many hours has been wasted on that ? LOL
rucknium: This research team that has written multiple papers about eclipsing the Monero network has suggested increasing the white_list size for over a year.
rucknium: Simpler fixes are better than complex fixes, ceteris paribus.
ofrnxmr: Mine increases the size because its not reasonable to bucket peers with a small 1000 whitelist
interestingband: rucknium: Those ppl successfully wasted time in a spirit of academic research with their useless formalism. That's the most important part of academic research that should not be adopted by MRL.
ofrnxmr: white = 256 * 16 = 4096, gray he 256 * 32 = 8192. Iirc bitcoin is 256 * 64 = 16384
ofrnxmr: Mine ^
rucknium: This attack is very practical and not just hypothetical (formal) at all.
rucknium: I'll end the meeting here. We can continue discussing after.
interestingband: Yes, but your approach to solve it is wrong and solution is bad
rucknium: Thanks everyone.
interestingband: The same as OSPEAD, real attack / problem, but solution is bad
boog900: interestingband: rucknium: picked this up after multiple reports about how weak our address book is, in the latest paper they did a real attack on our seed nodes. The solution stops their attack. Yes it does not go all the way to make our address book and p2p layer completely secure but it could certainly be a stop gap while you work on a whole extra P2P layer.
boog900: Thanks rucknium 🙏
syntheticbird: Thanks Rucknium
interestingband: boog900: My commetns mostly about goal and analysis of the solutions for the stated problems (problems are kinda known already). Bcs most solutions I don't like personally can be rejected by anyone else who is doing proper indenpendent/unbiased analysis of them.
sgp_: interestingband: just propose PoS or whatever with nodes with stake getting connection preference
syntheticbird: nah spirobel already have the PoS proposer role
interestingband: I was talking about aligning p2p with PoW consensus, do you see a difference ?
sgp_: no I don't pls explain. PoS = PoW
sgp_: we can't have 2 people championing similar ideas or else it might make progress
interestingband: sgp_: Please make sure that you are not touching any code with this depth of understanding of reality.
boog900: Its easy to say it would be better to do XYZ, but until XYZ is done all we have is Ruck's PR.
sgp_: yeah ruck's is a trivial fix with clear immediate benefits. it's not meant to be a comprehensive solution
jpk68: lmfao
syntheticbird: jpk68: ssssshhhhhhhhhhhhhh
jpk68: sgp_: ^
jpk68: That's what I meant to reply to, oops
syntheticbird: Don't say oops. Impose your mistakes.
gingeropolous: interestingband: if you wanna read the great stat machines output from your entropy: https://github.com/Fountain5405/monerosim/blob/hashrate-gating/README.md
syntheticbird: inb4 your sim sucks because you didn't specify things correctly and its all your fault
syntheticbird: also I have a working prototype that is much better
gingeropolous: its not even a sim at this point, just arithmetic.
syntheticbird: gingeropolous: don't underestimate one's blindness in front of a proof
interestingband: boog900: Btw, I think approach with independent ref implementation is a nice way forward, but it can be done faster I think than how it's going with cuprate atm.
spirobel: reductive > syntheticbird: nah spirobel already have the PoS proposer role
gingeropolous: although i do like what the bot came up with as an alternative sorta based on it: "5a. Inbound connections beyond a per-/16 quota pay a workshare per handshake"
syntheticbird: spirobel: how so? You are very into proposing PoS. Does that remove any of your other accomplishment?
syntheticbird: no
interestingband: syntheticbird: top-bottom analysis doesn't require looking into simulation numbers, since my comment was about simulation model setup and it's assumptions.
spirobel: syntheticbird: we talked extensively about this. People can just read the comments i made back then and left on the PoS CCS
syntheticbird: well ok sorry for the joke
boog900: interestingband: Nice 👍️
syntheticbird: interestingband: how?
interestingband: sgp_: Atm There are 2 approaches for the best consensus, and it's either PoW (but it requires diff logic around RandomX) or something called proof-of-pledge based on physical devices with real pledge inside, so it's not a ephemeral PoS with nothing at stake, but it's a stake per participant, and it looks like it can't be implemented in reality due to some fundamental reasons.
boog900: syntheticbird: Just yolo slop it all
interestingband: syntheticbird: How ? 1. stop writing prose about code, and write code, 2. ...
syntheticbird: interestingband: That's my bad. I was expecting some constructive from your mouth but ig I set the bar too high.
boog900: You know a lot about writing code and not talking right?
interestingband: syntheticbird: Nah, i've just commented about your blog post about code, it's a waste of time
syntheticbird: interestingband: just imagine if I gave a fuck
syntheticbird: about your opinion
syntheticbird: imagine
sgp_: ooh this pledge thing sounds fun, is it like the pledge of allegiance to monero. nodes need to prove they are true people who have sworn allegiance, and aren't a bad guy. so kinda like a permissioned network cult, but cool
interestingband: LOL
gingeropolous: instead of getting hostile i recommend the ignore feature of this glorious technology
syntheticbird: sgp_: putting symbolism on the protocol like that would be hilarious
sgp_: ok i'll stop sorry. put up or shut up with a written, organized, well-reasoned proposal
sgp_: until then I don't care about comments about some mythical PoW node selection basis
interestingband: sgp_: Nah, it's about real resource backing digital token, any real resource locked in a box
gingeropolous: im tellin yah, there might be something in the botslop: " Inbound connections beyond a per-/16 quota pay a workshare per handshake"
interestingband: sgp_: In the context of MRL, there is a need for a formal proof for cryptography, but atm it's just audits with "opninions", so is your advice applicable to your own efforst or no ?
interestingband: Anyway, I'm talking about research relevant for monero, it doesn't contradict with the purpose of MRL
sgp_: uh, no
sgp_: https://magicgrants.org/2026/09/29/Divisors-in-Monero
sgp_: see "The Latest Development: zkSecurity's Formal Verification"
interestingband: I can't submit CCS proposal due to downtime, and any work upfront isn't eligible for funding, so that's why it's private atm > sgp_: ok i'll stop sorry. put up or shut up with a written, organized, well-reasoned proposal
sgp_: and also see "What Formal Verification Doesn't Tell Us"
interestingband: sgp_: That one is nice, I even reacted to your comment about it back then. But it's not enough, and it's just 1 audit
interestingband: sgp_: My entry is effect in reality, I never chase goals that are disconnected from reality. I guess my formal verification is a bit different from what is done by others.
syntheticbird: interestingband: You can there is a pastebin for it
interestingband: operations CCS means all types of participants can interact with each other, offline archive / queue of proposals isn't operational CCS
interestingband: syntheticbird: I hope you are not touching any critical code with this depth of understanding of reality.
syntheticbird: ^ > interestingband: Please make sure that you are not touching any code with this depth of understanding of reality.
syntheticbird: sense of humor or genuinely low IQ ?
interestingband: I've never reviewed any code written by you, but I just don't know any human who can solve complex problems with code and like to write prose about code at the same time.
syntheticbird: I need to frame this message on my wall
syntheticbird: this is peak comedy
interestingband: https://github.com/Cuprate/cuprate/pull/100 https://github.com/Cuprate/cuprate/pull/6, 2 PRs where you add relatively big change and then wipe it later, so it doesn't look like I'm wrong, LOL
interestingband: I don't argue about your ability to write prose, you are probably good at it
rucknium: This conversation can be moved to #monero-research-lounge:monero.social
thomasbuilds: yeah u guys need to move from the lab and go sit on the long chairs
ofrnxmr: Ok, we dont needthe echo
thomasbuilds: arguing in the lab can break a sample and boom next corona virus comes out
interestingband: rucknium: ok, I have nothing more to add on that topic atm
https://libera.monerologs.net/monero-research-lab/20261028#c717146

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

gingeropolous reported that simulations are ongoing (links shared ...

2026-10-29T17:49:27Z

gingeropolous reported that simulations are ongoing (links shared earlier). So far SoP defeats the classic selfish miner, but the bot finding attack strategies reduces efficacy somewhat. A recent finding indicates that a real network with multiple honest mining nodes may favor the attacker. rucknium skimmed the notes and script, doubted a true MDP was used (exact MDP should be an upper bound; no MDP solver libraries were imported), and flagged a statement that appeared incorrect. gingeropolous welcomed direction on how to guide the bot. rucknium offered to write notes on his current thinking. gingeropolous will update today’s note and asked what else needs to be proved before inclusion.

rucknium: 6. Share or Perish (selfish mining mitigation) (https://github.com/monero-project/research-lab/issues/146).
rucknium: gingeropolous: Do you want to explain what the bot found?
gingeropolous: sims are ongoing. i posted a link at the top. i can copypasta again. im kinda in another meeting. basically so far SoP defeats the classic selfish miner. the bot figuring out ways to attack SoP brings down the efficacy somewhat.
gingeropolous: and the recent finding indicates that a real network, one with multiple honest mining nodes, may push the equation towards the attacker.
rucknium: Since you posted, I skimmed this https://github.com/Fountain5405/monerosim/blob/sop-research/docs/20261025_sop_mdp_notes.md and https://github.com/Fountain5405/monerosim/blob/sop-research/scripts/sop_mdp.py
rucknium: I doubt that the bot did a real MDP, but I could be wrong.
gingeropolous: well any direction is appreciated. Anything i can feed the bot to get it to do whats expected.
rucknium: And this one https://github.com/Fountain5405/monerosim/blob/sop-research/docs/20261028_mrl_status.md
rucknium: This seems wrong to me:
rucknium: > Exact MDP (a lower bound only) and a tabular learner could not beat the hand-written family
rucknium: Exact MDP should be an upper bound. It should be the optimal strategy by the adversary.
rucknium: And the python script didn't import any MDP solver libraries.
gingeropolous: word, thanks.
rucknium: gingeropolous: I don't speak bot language. 🤷
rucknium: I guess I can write some notes about my current state of thinking.
rucknium: That should be helpful to humans, too. Anything else on this item?
gingeropolous: i will update the the note for today. I can't think of anything else - im just trying to gather data to support inclusion at some point. Does anyone have any other thoughts on what needs to be proved before its used?
https://libera.monerologs.net/monero-research-lab/20261028#c717130

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

jberman reported the release of beta stressnet v3.1, which ...

2026-10-29T17:46:34Z

jberman reported the release of beta stressnet v3.1, which includes the inflation patch for the 24-hour fork window, GUI fixes from latest upstream, faster scanning, and some DoS prevention. Follow-up GUI issues remain (one fixed by selsta; potential connection issues). Plans for next week: review tx relay v2 logs from the high-stress period of v3 beta, and review/integrate tevador’s relative lock implementation. rucknium noted the stressnet is currently relaxed and offered to start spamming after hearing specific objections and log items to watch. ofrnxmr preferred controlled tests because the DB would become massive, and noted unusually high alt chains during the last stress (to investigate next time). gingeropolous mentioned stressnet.moneroworld.com for data scrapers. jeffro256 attributed some alt-chain activity to his own miner reconnecting after internet outages. rucknium will wait to spam until after jberman’s log review. jberman linked an issue on the alt chains.

rucknium: 5. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/).
jeffro256: If implementing FCMP++ becomes 1.4% easier each annum, then in 600 years we can implement FCMP++ in under a second
jberman: we released beta stressnet v3.1 which included the inflation patch for the 24 hour fork window, GUI fixes from the latest upstream code, faster scanning, and some DoS prevention. Still some followup GUI issues to check up on (selsta fixed one, and some potential connection issues)
rucknium: Stressnet is not very stressful at the moment. Maybe you could even say it's relaxed. I could start spamming soon, but I want to hear specific objections and things to look for in logs.
jberman: 2 things I'm planning to do in the next week: 1) review tx relay v2 logs during the high stress period of v3 beta, and 2) review / integrate tevador's relative lock impl
ofrnxmr: I think its good being relaxed atm, since the db would be massive if not. I think we shoukd organize / plan when to stress it, and when to not. Basically doing sonewhat controlled tests
ofrnxmr: I still saw the last stress on oxblocks that we have an unusually high amount of alt chains
ofrnxmr: So probably something to look at the next time we do it
gingeropolous: theres also stressnet.moneroworld.com , if anyone wants to run a datascraper on their node
jberman: ack
jberman: ofrnxmr: https://github.com/seraphis-migration/monero/issues/508
jeffro256: ofrnxmr: A lot of that was me when my internet went out for unrelated reasons, but my miner would try mining immedately after it came back online
rucknium: I will wait to start spamming at least until after jberman "review[s] tx relay v2 logs during the high stress period of v3 beta"
https://libera.monerologs.net/monero-research-lab/20261028#c717114

quoting
nevent1q…4ysw
FCMP beta stressnet
https://github.com/seraphis-migration/monero/releases/
nevent1qqs93sytft5tc65wnkxm6lcc4zuuyq8hfnq2vgfps4ur2mche6c3crcxuxyer

jberman reported that integration PRs are ready for review with ...

2026-10-29T17:42:39Z

jberman reported that integration PRs are ready for review with followups implemented. Quotes for the integration audit are being fielded; final quotes and internal discussion are expected by next week. interestingband asked for the expected timeline including the hardfork date and stated an independent approach (spec, formal verification, ref implementation, performance testing) that can be done alone with AI, while also noting a possible Bulletproofs++ path for ~50% smaller membership proofs (PoC exists but not formally proven). jberman hoped for all code ready in Q1 and preferred reviews over full reimplementation. jeffro256 argued against waiting indefinitely for perfect unproven solutions, favoring the historical approach of moving forward then replacing modules. interestingband provided a short code snippet link and reiterated that the current work lacks a single spec and formal proof. sgp_ suggested discussing the BP++ idea separately; jberman saw it as interesting for a follow-up fork.

jberman: integration PR's are ready for review, followups implemented
jberman: we're fielding quotes for the integration audit and discussing them internally, I think we should have final quotes and discussion by next week
jberman: > interestingband: FCMP todo list: spec for it (no single spec), formal verificaiton of spec (most audits are just not reproducible "opinions"), ref implementation, performance testing (benchmark of ref implementation under simulated load), done; No idea what is a purpose of the meeting if 1 person can do it all with AI instead of bunch of humans walking in circles for few years;
jberman: interestingband wants to do all this too, so nice
interestingband: One q, what is expected timeline for it all at the moment including date for the actual hardfork ?
jberman: personally hoping all code is ready Q1. reviews would help move things along rather than trying to redo everything your way
interestingband: My approach is indepnedent on what others are doing and it's the only way to get the best result that I would be ok myself.
jberman: ok
interestingband: Btw, there is likely a way to use bulletproofs++ like instead of generalized bulletproofs and it allow 50% smaller membership proofs
interestingband: I have PoC and it looks feasible, but proven yet formally
jberman: IIRC Aaron had some reservations on BP++
interestingband: And there is little difference to verify formal proof with generalized bulletproofs or bulletproofs++ as proving system
jberman: but that does sound interesting
sgp_: This may be best to discuss separately
interestingband: sgp_: ok
jberman: imo would be interesting for a followup fork fwiw
rucknium: More on this item?
jeffro256: If we wait on perfect unproven solutions indefinitely, then no one gets FCMPs. Better to do what we've done in the past, which is: move forward, then replace modules with more efficient alternatives. There's a lot more work in doing a FCMP-style hardfork for Monero then just the BP code
interestingband: some real numbers for what is likely feasible
interestingband: https://mrelay.p2pool.observer/p/vbPv6LgLOEc0dnZP/1.txt (code snippet, 5 lines)
rucknium: jeffro256: Need to start doing a wait calculation for FCMP https://en.wikipedia.org/wiki/Interstellar_travel
interestingband: jeffro256: (the point is that current isn't proven, it doesn't even have a spec to prove, but once you have it, proving small change is easy, once you have full setup)
interestingband: jeffro256: (and privacy leak in carrot is an example of what wasn't proven in it, after your changes it's still unproven, it's just that you addresses discovered so far edge cases)
interestingband: jeffro256: (and my initial goal was to verify/prove what is written so far, bulletproofs++ addon is just a discovery in the process)
https://libera.monerologs.net/monero-research-lab/20261028#c717091

quoting
nevent1q…q38z
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
nevent1qqst8wwxmfugpcxevgdk6dk03hh990vknrknvd2vf4p6zscevyn393g5qhff3

jeffro256 reported that the Carrot spec and implementation are ...

2026-10-29T17:39:06Z

jeffro256 reported that the Carrot spec and implementation are ready for review. Spec: https://github.com/jeffro256/carrot/pull/16 ; impl: https://github.com/monero-project/monero/pull/9559. InProofs continue to work for incoming payments; OutProofs work for external outgoing payments. For self-sends, InProofs take a different form (leaking that the enote is internal) and there are no OutProofs. External self-sends in >2-out txs can still have both. The main UX impact is limited to internal enotes. rucknium noted a potential cryptographic audit-trail impact for self-sends and asked whether Carrot view keys still allow a full trail. jeffro256 clarified that without tx-specific secrets (or a new derivation from permanent secrets), outgoing information is lost beyond total amount per tx; giving up the view-balance secret makes the PR 16 change moot. OutProofs can always be made for external enotes (even to oneself). The workaround of external self-sends preserves most current UX. Participants viewed the outcome as reasonable.

rucknium: 3. get_tx_key/check_tx_key doxes sender in 2-out tx (https://github.com/monero-project/monero/issues/11586).
rucknium: Is jeffro256 here?
rucknium: Anything to discuss on this item for now?
jeffro256: Yes , the spec and the impl are ready for review
jeffro256: I'll drop links rn
jeffro256: Spec: https://github.com/jeffro256/carrot/pull/16
jeffro256: impl: https://github.com/monero-project/monero/pull/9559
jeffro256: If tevador is here, I'd like to ask whether he sees any incompatibilities of these changes w/ Jamtis
jeffro256: Maybe not, but good review from any parties would be appreiated
jpk68: My bad for the likely uninformed question, but what was the trade-off for the chosen fix, again? Was there an option found to not slow down scanning or remove Janus attack protection?
jeffro256: Good question. InProofs still work for incoming payments. OutProofs still work for external outgoing payments. There is also InProofs possible for selfsends, but they take on a different form. I.e. they leak to the verifier whether the enote is internal.
jpk68: Ah, good to know, thanks. So essentially, the only disadvantage is with self-sends (?)
jeffro256: Yes
jeffro256: Which IDK how often InProofs/Outproofs are used for self-sends, but I'd like to preserve most of the UX if possible even if I never use it
jeffro256: But yeah the main difference is for internal enotes only: no OutProofs, and InProofs look different.
jeffro256: https://xkcd.com/1172/
jeffro256: Although not explicitly recommended by the spec, nothing prevents you from making external enotes to yourself in >2-out txs and having both OutProofs and InProofs like today
rucknium: The possible UX impact is a cryptographic audit trail when you have a self-send somewhere in the trail? Can you still get the full trail with the Carrot view keys?
jeffro256: Define "full trail"
rucknium: I get some XMR. I self-send one or more times. I send it back out to someone.
jeffro256: W/o tx-specific secrets, or a new way to derive tx-specific secrets from your permanent account secrets, then outgoing information is lost, besides total amount per tx
rucknium: Does the lack of outproofs for self-sends affect me?
jeffro256: If you are giving up view-balance secret anyway, then no. The change in PR 16 is moot
jeffro256: You can always make OutProofs for external enotes
jeffro256: Even if they go to yourself
jpk68: As in, an external wallet also controlled by you?
rucknium: Thanks for coming up with the work-around. Seems like a good outcome.
jeffro256: jpk68: Any wallet: current wallet, other wallet held by you, or other entity with unknown key material
jeffro256: Same situation as current. Any "OutProof" you verify doesn't actually mean that the funds left custody of the person making an OutProof
https://libera.monerologs.net/monero-research-lab/20261028#c717056

quoting
nevent1q…jq6a
get_tx_key/check_tx_key doxes sender in 2-out tx
https://github.com/monero-project/monero/issues/11586
nevent1qqsfdmtt0uj8flk0rzkf42rtvx8gvxtuy2x3d8pt8lv7ln8huvnggnqsws97n

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

2026-10-28T14:23:56Z

In reply to nevent1q…j2yk
_________________________

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

Share or Perish (selfish mining mitigation) ...

2026-10-28T14:23:05Z

In reply to nevent1q…g2hh
_________________________

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

FCMP beta stressnet ...

2026-10-28T14:20:35Z

In reply to nevent1q…j2uw
_________________________

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

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

2026-10-28T14:20:05Z

In reply to nevent1q…9r9m
_________________________

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
nevent1qqst8wwxmfugpcxevgdk6dk03hh990vknrknvd2vf4p6zscevyn393g5qhff3

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

2026-10-28T14:18:10Z

In reply to nevent1q…c6yr
_________________________

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

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

2026-10-28T14:16:43Z

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

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

jberman planning v3.1 release today with already-merged fixes ...

2026-10-22T04:21:34Z

jberman planning v3.1 release today with already-merged fixes (including GUI wallet reopening fix; QT6 can be included). Will review spam-period logs to confirm tx relay v2 holds up before upstream merge. Some xmrack findings noted; AI reviews welcome in the seraphis-migration repo.

jberman: Planning to put out a v3.1 release today that includes the already merged fixes into the stressnet branch (including a fix for reopening wallets with GUI)
ofrnxmr: jberman: gui qt6 now too?
jeffro256: Thanks to selsta for fixing the GUI issue
ofrnxmr: (Get to test the unrelease "major" gui update)
jberman: ofrnxmr: Yep can include that too
ofrnxmr: Its merged on master on gui repo, so i assume its included, i think
jberman: Yea I just have to update the branch I'm using for these builds
jberman: I also want to check logs during the spam period to make sure tx relay v2 is holding up as expected, and then the upstream tx relay PR should be ready for upstream merge
jberman: I have logs, just need to review them
ofrnxmr: There were some xmrack review finsing that should be addressed soon
jberman: I can't recall if there are more beyond the PR's xmrack opened (and have been merged into the stressnet branch as well)
jberman: FWIW I personally don't mind people posting solid AI reviews in issues in the seraphis-migration repo so we make sure to keep track of them that way
https://libera.monerologs.net/monero-research-lab/20261021#c715994

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

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

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

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

2026-09-23T03:17:04Z

In reply to nevent1q…mdd5
_________________________

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-23T03:15:18Z

In reply to nevent1q…6r8h
_________________________

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

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

Bulletproofs+ Aggregate Range Proof Issue Identified and Resolved ...

2026-09-23T03:04:39Z

Bulletproofs+ Aggregate Range Proof Issue Identified and Resolved
MAGIC Grants commissioned Dr. Wang and Dr. Liu for an independent security review of the Bulletproofs+ aggregate range proof after an issue was identified. The full report is available.
https://magicgrants.org/2026/09/22/Bulletproofs+-Report
https://x.com/MagicGrants/status/2102526550851653755

rucknium could not run reproduction code but finds the attack ...

2026-09-17T03:55:35Z

rucknium could not run reproduction code but finds the attack plausible: poison peerlists so unreachable nodes only connect to adversary peers. Suspected flaws: inbound connections pace whitelist inserts; 1,000-peer whitelist (from CryptoNote https://github.com/monero-project/monero/blame/9e3a31032ee2cf3cb65c908e107a9952d03bbc4f/src/cryptonote_config.h#L138-L139). gingeropolous’s Shadow/monerosim runs partly confirm; unmodified monerods only filled 7/12 slots, hyper-injection still running. SEED Emulator used. boog900: weak eager whitelist; look at Bitcoin addrman https://bitcoincore.academy/addrman.html https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md ; Cuprate similar, planned change. Responsible disclosure via HackerOne; prior log https://libera.monerologs.net/monero-research-lab/20260913#c707269 . Prior Shi 2025 NDSS paper [44] already discussed whitelist mitigations unadopted. rbrunner’s /24 dedup PR https://github.com/monero-project/monero/pull/9939 raised attack cost. Ideas: 10x whitelist, inbound not writing whitelist, inbound/outbound insert pairing, incoming connection limits, only evict unreachable from whitelist. Eclipse impact: spy on tx origin or isolate nodes (majority unreachable, often GUI). Continue next week.

rucknium: 8. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260)
rucknium: Finally here. And we have held on to rbrunner !
rbrunner: Indeed.
rucknium: Probably best to have an initial discussion, with plans to continue in more depth next week.
rucknium: Is boog900 here?
boog900: Hi
boog900: yes
rucknium: I am skeptical of the paper because I cannot get their reproduction code to run. However, I find their theorized attack to be plausible, given monerod's design decisions.
rucknium: Basics: An eclipse attack happens when an adversary (who wants to do something bad) completely isolates one or more honest nodes from the rest of the network. The honest node thinks it's connecting to other honest nodes, but actually all of its peer connections are to a node (or pseudo-node) controlled by the adversary.
rucknium: So they say they can eclipse unreachable nodes (nodes that are behind firewalls so they do not accept inbound connections) by poisoning the peerlists of honest nodes. The honest nodes inadvertently give the targeted unreachable nodes the peerlists of the adversary.
rucknium: I think it's caused by two design decisions that may be design flaws:
rucknium: 1. Allowing inbound connections to control the pace of adding new IP addresses to honest nodes' peerlists, specifically their whitelists.
rucknium: 2. Limiting the white list to 1,000 peers.
rucknium: If you fix one or both of those, you would fix the attack probably. If the attack actually works.
gingeropolous: so far my replication attempts are confirming the findings, but I'm running into issues with shadow. Currently running what I hope is the final run.
rucknium: The paper uses "SEED Emulator", which is supposed to be simulator to Shadow.
boog900: monerod does have a very weak address book, it is very eager to swap out peers in the white list
rbrunner: Well, that magic number of 1000 sounds like a limit set in earlier time when RAM was smaller than today. Maybe no problem to lift that
gingeropolous: Interestingly, the initial run of the entire 2.2k nodes used real monerods, and was only able to get 7/12 occupied. So if the attack was mounted using un-modified monerods, our protocol holds. But the peer list hyper injection that they did is different, and that sim is running.
rbrunner: you mean special nodes that "cook up" special peer lists, and fast?
boog900: Cuprate has this issue too, but that is planed to be changed. IMO we should look at Bitcoin's address book which is much more resilient
rucknium: The 1000-peer limit in the white list was inherited from the original cryptonote codebase: https://github.com/monero-project/monero/blame/9e3a31032ee2cf3cb65c908e107a9952d03bbc4f/src/cryptonote_config.h#L138-L139
gingeropolous: essentially a synthetic node - a python process that pretends to be a monerod, does the p2p dance, and then sends bad peers
rbrunner: I see
rucknium: boog900: The paper says that bitcoin's eviction design may be more vulnerable by nature. But they probably have patches to make it less vulnerable.
rbrunner: Without looking into this closely, I find it kind of counter-intuitive that this should fully succeed, but may there is some re-inforcement, or runaway effect in play, until the daemons are totally poisoned
rbrunner: I think simulations are very valuable here
rucknium: My instinct is to just raise the white list by 10x. I don't know if that would have downsides. I haven't read all the bitcoin and ethereum eclipse papers. Maybe there is something valuable there. Or cautionary about raising the list size limit too much.
rbrunner: Also for later testing any changes, it might be able to inadvertantly make things worse ...
rucknium: Ideally, if there are X% adversary nodes, only X% of honest nodes' white lists should be composed of adversary node IP addresses.
rucknium: But they can push that up by quickly connecting to honest nodes from 1,000 adversary "nodes". Then it fills their white list.
absinthium: unrelated, did the researchers that wrote the paper make any attempt to responsibly disclose their findings to us prior to releasing it?
rucknium: absinthium: Yes. They submitted a HackerOne report. They state that in the paper, too.
boog900: I'll have to read what they said there, but Bitcoin does not give up spaces in its address book as easily as monerod which should make it slightly more vulnerable at start up but less once running with a full peer list. > rucknium: boog900: The paper says that bitcoin's eviction design may be more vulnerable by nature. But they probably have patches to make it less vulnerable.
rbrunner: Formulated this way, this sounds surprisingly logical :)
rucknium: absinthium: See https://libera.monerologs.net/monero-research-lab/20260913#c707269
plowsof: https://bitcoincore.academy/addrman.html
rucknium: Say that inbound connections do not get added the to the white list. Would that have an unacceptable affect on new nodes getting added to the "network-wide" white list?
rucknium: Or say that for every peer added to the white list by in inbound connection, you would have to wait for one to be added by an outbound connection (i.e. through graylist promotion). Would that slow down the pace of the adversary packing its IPs into white lists?
rbrunner: Don't know, my gut feeling tells me that with drastic changes like these you can easily make things worse. But not really much more than a gut feeling.
rbrunner: Anyway, I guess things also have to work in edge cases, like only seed nodes ready to accept incomming connections and everybody else closed against that
rucknium: There is a balance between letting the honest nodes establish sufficient connectivity and not letting the adversary nodes establish excessive connectivity.
rucknium: The paper says
rucknium: > The whitelist-filling primitive is reused from [ 44 ], and its mitigations, such as blocking whitelist insertion from incoming connections or increasing whitelist capacity, have already been discussed but remain unadopted by Monero.
boog900: that is for the incoming connection limit from what I can see > rucknium: boog900: The paper says that bitcoin's eviction design may be more vulnerable by nature. But they probably have patches to make it less vulnerable.
rucknium: [44] is Ruisheng Shi, Zhiyuan Peng, Lina Lan, Yulian Ge, Peng Liu, Qin Wang, and Juan Wang. 2025. Eclipse Attacks on Monero’s peer-to-peer Network. In Network and Distributed System Security (NDSS) Symposium.
gingeropolous: i gg, but will post results when i have them
rucknium: Thanks, gingeropolous
boog900: monerod doesn't have a limit on incoming connections, so an adversary can't fill all incoming slots. But this isn't Bitcoin's address book
boog900: Although IMO monerod should also have an incoming connection limit just for DoS prevention
rucknium: IIRC the discussion about Shi et al. (2025) went like this: Vulnerabilities were patched, but the bigger discussion was not instigated because there was little to worry about after the patches.
rucknium: boog900: I see. They mean "eviction" as in connection eviction, not address book eviction. I was confused because they mention Ethereum's incoming-connection limits like it is something different from what bitcoin does.
rucknium: > s. In Monero, for example, the lack of
an eviction mechanism [44 ] prevents an attacker from actively
expelling honest connections, and the absence of a strict cap on in-
coming connections makes it difficult to block new honest incoming
peers. In contrast, Bitcoin’s eviction policy [ 2, 25 ] and Ethereum’s
incoming-connection [ 43] limits can be more readily “leveraged” by
attackers to complete an eclipse
rbrunner: Seems to me that there is quite some stuff to study and fish for good ideas :)
rucknium: boog900: I am hesitant to just have Monero copy what Bitcoin does. Maybe by accident a more resilient design could come out of the cryptonote protocol :)
rucknium: Not to mention the risk of replacing big chunks of critical code
boog900: Yeah I only got it from the link [2]: https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md
rbrunner: By the way, if they want maximum harm, or maximum damage, what will the adversary do with those fully eclipsed nodes?
rbrunner: I mean, yeah, stopping all transactions from propagating, but is there more?
rucknium: rbrunner: Either complete spying on origin of tx or completely make the nodes unusable.
boog900: rucknium: I agree but Bitcoin does have a much better address book IMO I have looked into its logic from a high level. We don't need to copy everything but some core parts would help us a lot.
rucknium: Unreachable nodes are the majority of the network, probably. Many of them are users at home with the Monero GUI wallet.
boog900: like only removing unreachable peers from the white list
rucknium: This is a good paper on many network-level attacks, including eclipse: Franzoni, F., & Daza, V. (2022). "SoK: Network-Level Attacks on the Bitcoin P2P Network." (https://moneroresearch.info/232)
rucknium: We can continue discussion on this paper next week. Any last thoughts?
rbrunner: Hmmm. So worst case somebody could quietly establish something like a network on top of the real network, and over time spy on everything.
rbrunner: Ha, we are all living in the Monero network matrix already :)
rucknium: Like mentioned prior to the meeting, the paper says rbrunner 's recent patch increased the cost of the attack: p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes' https://github.com/monero-project/monero/pull/9939
rbrunner: But maybe hard to achieve further improvements on the selection front. Better list management is probably wide open for improvements compared to that
rucknium: We can end the meeting here. Thanks everyone.
rucknium: I guess you could figure out if you are eclipsed by doing a full network crawl once daily. Then if most of the network disappears from one day to the next, you know you've been eclipsed.
rucknium: But what if the adversary does it gradually?
vtnerd: You can ask anyone in the chat of hash+block#. Assuming the goal is fake blocks, it's hard to completely fake all avenues of checking that. Additionally there's the hashpower which would be lower
https://libera.monerologs.net/monero-research-lab/20260916#c708293

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

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

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

2026-09-16T00:18:35Z

In reply to nevent1q…57j5
_________________________

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

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 said all side PRs are ready for beta v3; remaining work ...

2026-09-09T20:29:07Z

jberman said all side PRs are ready for beta v3; remaining work is the hot/cold wallet PR, then a rebase on latest master. sech1 plans to start testing a minimal P2Pool v5 FCMP++/Carrot build on stressnet next week.

jberman: All side PR's are prepared for beta v3, next is just hot/cold wallet PR then rebasing on latest master
sech1: P2Pool v5 is progressing at a good pace, I think I'll start testing it on the stressnet next week - not a feature complete version, but a version with minimal required FCMP++/Carrot code
https://libera.monerologs.net/monero-research-lab/20260909#c706719

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

tevador "tried to add some tests to the relative locks PRs, ...

2026-09-09T20:25:19Z

tevador "tried to add some tests to the relative locks PRs, but got stuck on a hack in the FCMP++ test code: https://libera.monerologs.net/no-wallet-left-behind/20260906#c705669";. rucknium asked whether relative locks interact with the old lock style being deprecated because FCMP makes locked-tx tracking harder. . rucknium asked whether relative locks interact with the old lock style being deprecated because FCMP makes locked-tx tracking harder. tevador said no: relative locks work differently and do not affect tree building. git blame on the test lines was unusable because they sit in a mega-commit; jberman later said he wrote that code and would reply in #no-wallet-left-behind.

tevador: I tried to add some tests to the relative locks PRs, but got stuck on a hack in the FCMP++ test code: https://libera.monerologs.net/no-wallet-left-behind/20260906#c705669
rucknium: IIRC, one of the reasons that the old lock style is deprecated is because FCMP makes it more complicated to keep track of the locked txs. Does relative locks have any interaction with that? (I hope not).
tevador: No, the relative locks work completely differently. They have no impact on the tree building process.
rucknium: git blame doesn't work on those lines. It's just a mega commit, it says. I was going to ask who wrote that so they could be queried.
tevador: I don't want to delay the meeting, so if someone is familiar with the test code, we can talk in #no-wallet-left-behind.
jberman: just seeing that now, will respond in a bit tevador
jberman: I wrote that
https://libera.monerologs.net/monero-research-lab/20260909#c706709

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

rucknium presented the first known Dandelion++ spy-node ...

2026-09-09T20:19:30Z

rucknium presented the first known Dandelion++ spy-node resistance test on a network of real running Monero nodes. The test had two aims: measure D++ against a spy-node adversary, and establish a statistical method for monerosim. Results matched the D++ paper: "monerod is achieving a p percent detection of the true tx origin when the network is made up of p percent spy nodes.
In the gist, I use cluster-robust inference to augment the usability of a small number of simulations."
rucknium noted limits: no unreachable nodes, no spy-node peer-list stuffing, and no embargo-timer / black-hole / packet-loss cases.
tevador said real spies do not behave like honest nodes "it's a good sign that our D++ implementation is working".

rucknium: This little project had two purposes. First, to test the resistance of Monero's implementation of Dandelion++ against a spy node adversary. Second, to test and establish a statistical methodology to use the monerosim network simulator to measure network behavior.
rucknium: AFAIK, this is the first test of Monero's D++ spy node resistance that uses a network of real running nodes (please correct me if I am wrong).
rucknium: Congratulations, it passed!
rucknium: Especially congratulations to vtnerd who coded most of the D++ implementation AFAIK. And the helpers and reviewers.
rucknium: monerod is achieving a p percent detection of the true tx origin when the network is made up of p percent spy nodes. That is what the D++ paper claims in its theorems.
rucknium: In the gist, I use cluster-robust inference to augment the usability of a small number of simulations. The problem I'm overcoming is that multiple measurements in the same simulation are not statistically independent.
rucknium: The paper that described D++ (Fanti et al. 2018) actually did not run a network of bitcoin nodes with D++ implemented to test D++. Instead, they used simplified python simulations and a lot of theoretical results. They did implement D++ in a bitcoin patch, but they just used it to test network propagation latency on bitcoin's mainnet.
rucknium: Later, this paper actually did use real bitcoin nodes inside Docker containers to test D++: Franzoni & Daza (2022). "Clover: An anonymous transaction relay protocol for the bitcoin P2P network."
rucknium: monerosim is much better than a set of Docker nodes because it actually can use global internet latency data and its results are deterministic, i.e. the runs are reproducible.
rucknium: Lots of thanks to gingeropolous who has helped fix issues in monerosim as I've encountered them.
tevador: It's an interesting test, but in practice, spy nodes don't have the same way as honest nodes. For example, they try to stuff their peer lists with other spy nodes.
tevador: behave*
rucknium: tevador: Yes. There are a lot of ways that the simulation isn't realistic, but I wanted to, at least at first, reproduce the D++ theoretical results.
rucknium: For example, the simulation has no unreachable nodes, but Monero mainnet probably has a majority unreachable nodes. The D++ paper ignored unreachable nodes, so I did, too, in this test. monerosim has the capability to have unreachable nodes, but I did not use it here.
tevador: But it's a good sign that our D++ implementation is working.
boog900: This test was without the changes to the embargo timer right? I wonder if that would meaningfully change anything (probably not)
sgp_: rucknium: do you consider monerosim to be "finished" or are there some things that you are still working on?
rucknium: There are numerous extensions of this test I could do. Or I could try another type of measurement with monerosim. I am open to either. I think I would prefer to prioritize looking again at proposed selfish mining defenses, but input on my priorities is appreciated.
rucknium: boog900: I was wondering the same thing. I think the embargo timer would come into play with active spy node behavior, i.e. executing black hole attacks. Or increasing the packet loss rate in Shadow.
sgp_: Is there anything you’ve already decided needs to be added/extended and will work on that next, or are you looking for fresh ideas?
rucknium: sgp_: That's a good question to also ask gingeropolous . I think all the basic functionality is there. Another purpose of doing this was to encounter problems that needed to be fixed or bring up feastures when doing a real analysis, which we did.
sgp_: Basically: what do you plan to do next, I guess. The selfish mining?
rucknium: sgp_: Fresh ideas are good.
rucknium: Yes, i want to go back to selfish mining. I anticipate I won't use monerosim much for that. Maybe at the final stages of a proposed implementation, but not at these earlier stages. I am trying to get some "hidden" metrics in Markov Decision Process results in some earlier papers.
rucknium: Here are some of the issued I found and were addressed by gingeropolous : https://github.com/Fountain5405/monerosim/issues?q=is%3Aissue
rucknium: Well, ClaudeAI addressed them, but gingeropolous guided it.
rucknium: By the way, I think log parsing could slow down other investigations with monerosim. I already had code written to parse tx broadcast logs, but you would need other ways to parse the logs for other investigations and metrics.
rucknium: I mean, monerosim should theoretically be usable by any dev who wants to analyze some patch.
gingeropolous: re: monerosim and spy nodes, you could script the spy nodes to stuff their peer lists. anything you can do to a monerod you can do to it in monerosim. its just monerod. Re: monerosim and selfish mining, currently thats not really possible. Due to the nature of shadow, you can't actually mine with monerod. For the current monerosim, me and the llms came up with a hack, which is documented in the repo. To get proper PoW sim and the associated dynamics, i need to monerod to integrate mining hooks so i can route the PoW request within monerod to something that mimics it. But as it stands thats a PR written by a bot so ermagerd prolly not gonna happen. Though i'll check with fable, maybe it can come up with a way to do selfish mining investigations with the current solution. though i think i already asked this... hrm...
gingeropolous: there's also a second PR by a bot waiting that allows for testing forks. I guess i could roll both into a patch thats applied to vanilla monerod for the time being
https://libera.monerologs.net/monero-research-lab/20260909#c706670

quoting
nevent1q…rgk6
monerosim spy node analysis:
https://gist.github.com/Rucknium/ba230a2bab8a446d0997b7b002bf3af6
nevent1qqszwdsvn2pnv6nnkhe7meuxnmm8lhakumkge55u560l4pdcatkzl8gjwtwec

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

FCMP beta stressnet: ...

2026-09-08T18:56:58Z

In reply to nevent1q…fy48
_________________________

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

Relative locks with FCMP++: ...

2026-09-08T18:55:08Z

In reply to nevent1q…u3u3
_________________________

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

monerosim spy node analysis: ...

2026-09-08T18:53:53Z

In reply to nevent1q…ckd2
_________________________

monerosim spy node analysis:
https://gist.github.com/Rucknium/ba230a2bab8a446d0997b7b002bf3af6
nevent1qqszwdsvn2pnv6nnkhe7meuxnmm8lhakumkge55u560l4pdcatkzl8gjwtwec

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

2026-09-08T18:51:41Z

In reply to nevent1q…p8wt
_________________________

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

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

2026-09-08T18:48:36Z

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

Jeffro256 recently put forward a proposal to continue to work ...

2026-09-07T19:38:07Z

Jeffro256 recently put forward a proposal to continue to work full-time on #Monero development, with focus on audits of the integration of Full-Chain Membership Proofs (FCMP++) and hardware wallet support for CARROT and FCMP++!
The proposal is now open for funding!
https://ccs.getmonero.org/proposals/jeffro256-full-time-2026Q2.html

Boog900 recently put forward a proposal to continue to work ...

2026-09-03T02:11:05Z

Boog900 recently put forward a proposal to continue to work full-time on Monero development, with focus on Full-Chain Membership Proofs (FCMP++) support for Cuprate!
The proposal is now open for funding!
https://ccs.getmonero.org/proposals/boog_3_months_cuprate_6.html

jberman said the remaining v3 blocker is hot/cold wallet work, ...

2026-09-02T18:05:03Z

jberman said the remaining v3 blocker is hot/cold wallet work, which is in progress. jeffro256 said major changes from jberman’s review are done; only renamings remain.

jberman: It's just hot/cold wallet stuff now, we're working on it
jeffro256: Al the major changes from j-berman's review are done AFAICT, just renamings left
https://libera.monerologs.net/monero-research-lab/20260902#c704920

quoting
nevent1q…8p6m
FCMP beta stressnet: https://github.com/seraphis-migration/monero/releases/
Version 3 launch checklist: https://github.com/seraphis-migration/monero/pull/415
nevent1q…4rap

rucknium relayed post-meeting comments from loop.ster: interest ...

2026-09-02T18:01:34Z

rucknium relayed post-meeting comments from loop.ster: interest in a spec exists, but only limited pro-bono time (~10%, with AI help) and no hard deadline; no one had opposed merging timelocks. A workable path is ongoing spec work as time permits, with a check-in in about a month. jberman said the spec work itself could be a CCS candidate and clarified he wants continued exploration of the feature, not “write the spec and then maybe.” loop.ster expects some cycles next week on Grease and did not advance it this week.

rucknium: After the meeting, loop.ster said:
rucknium: > Don't get me wrong, I am interested in pursuing this, it's about how much time I can spend on it. If it's completely pro bono -- my working assumption --, it's like 10% of my time, tops, and I'll be using AI to help accelerate things. So I can't commit to some deadline of "produce a spec by XX date or else timelocks don't get merged".
rucknium: > What's encouraging is that there wasn't anyone against merging the time locks from what I could tell, so that's a very positive indicator.
rucknium: And that mrelay link is a 404 for me now. Can anyone else see it?
slowbeardigger: 404 for me as well
rucknium: Ah, I can find the old Matrix chat room:
rucknium: > Basically what I can offer is that if there's a general understanding that I am working on a spec, as time permits, along with the idea that relative locks probably do get merged -- that could work. That way we're not stuck at point 0, and in a month or so, we can compare notes again and maybe we're at a point where things can solidify a bit.
jberman: One point I was kind of getting at: I think even work on this spec would potentially be a solid candidate for a CCS proposal. It would be helpful Research to help solidify adding features to Monero's consensus
loop.ster: oh I see. I read it as, write the spec and then maybe..
jberman: nay, sorry I was unclear
loop.ster: cool, well I suspect I'll have some cycles next week to work on grease. I didn't move anything fwd this week
jberman: my main point being I think that continuing on the path of exploring working with that feature would be appreciated
rucknium: Any more discussion of this topic?
loop.ster: nothing from me
jberman: same, thank you loop.ster
https://libera.monerologs.net/monero-research-lab/20260902#c704904

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

jberman: jeffro256 made good progress on hot/cold wallets looks ...

2026-09-02T17:48:03Z

jberman: jeffro256 made good progress on hot/cold wallets looks like, which we want in before stressnet v3 as well
Re: Research Tasks. The current remaining major task is having circuit + gadgets impl re-audited, and the fcmp-plus-plus audited. We're currently fielding quotes and talking to candidates answering questions etc.
jeffro256: I don't have much to add except that review and upstreaming is ongoing
https://libera.monerologs.net/monero-research-lab/20260902#c704890

quoting
nevent1q…elvt
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
nevent1q…74kl

Rucknium: Wrote a draft of methodology for using monerism to ...

2026-09-02T17:20:33Z

Rucknium: Wrote a draft of methodology for using monerism to estimate the effectiveness of spy node adversaries: https://gist.github.com/Rucknium/ba230a2bab8a446d0997b7b002bf3af6