MoneroResearchLab
Monero Research Lab (Unofficial)

https://github.com/monero-project/research-lab

#Monero Research Lab (Unofficial)
https://x.com/MoneroResearchL

Public Key

npub1m0ner0mtjgs74aghus7qxrxl7mqv06d4v8rz9pmnux2dpr4cmhmsjgcfay

NIP-05 Address

Profile Code

nprofile1qqsdheu3ha4eyg0275t7g0qrpn0ldsx8ax6kr33zsae7r9xs36udmacpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsy4e82c

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1m0ner0mtjgs74aghus7qxrxl7mqv06d4v8rz9pmnux2dpr4cmhmsjgcfay

Show more details

Last Notes

2026-10-22 04:32:56 GMT

- reply

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: https://mrelay.p2pool.observer/m/monero.social/GntqIKOcBTFOElHlHNuztuPj.png (outbound-adversaries-unreachable-moros.png)
rucknium: https://mrelay.p2pool.observer/m/monero.social/SgasbveRvyaqrYakzVbUDkgO.png (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
#nevent1q…vh9e

2026-10-22 04:28:48 GMT

- reply

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
#nevent1q…pz8x

2026-10-22 04:25:19 GMT

- reply

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
#nevent1q…r7th

2026-10-22 04:19:20 GMT

- reply

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
#nevent1q…0mgm

2026-10-22 04:15:35 GMT

- reply

3. get_tx_key/check_tx_key doxes sender in 2-out tx (https://github.com/monero-project/monero/issues/11586)
https://blossom.primal.net/ae9c70336686fb2d5dca1b2942208530982eaa6775e859e0467e6c9e94e95805.png
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
#nevent1q…5s64

2026-10-21 04:14:28 GMT

- reply

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

2026-10-21 04:11:25 GMT

- reply

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

2026-10-21 04:09:19 GMT

- reply

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

2026-10-21 04:03:43 GMT

- reply

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

2026-10-21 04:02:46 GMT

- reply

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

2026-10-21 04:01:09 GMT

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

2026-10-19 19:52:42 GMT

#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

2026-10-15 14:34:41 GMT

- reply

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
#nevent1q…waqq

2026-10-15 14:21:12 GMT

- reply

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
#nevent1q…waqq

2026-10-15 14:00:40 GMT

- reply

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
#nevent1q…ns78

2026-10-15 13:49:53 GMT

- reply

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
#nevent1q…hm0y

2026-10-15 13:43:49 GMT

- reply

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
#nevent1q…sldg

2026-10-13 23:17:27 GMT

- reply

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

2026-10-13 23:16:00 GMT

- reply

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

2026-10-13 23:15:08 GMT

- reply

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

2026-10-13 23:13:53 GMT

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

2026-10-08 03:03:47 GMT

- reply

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: https://mrelay.p2pool.observer/m/monero.social/YpBcrtEzNiVVBHaYDyErKhrY.png (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: https://mrelay.p2pool.observer/m/monero.social/mbvSyQoCpqeFIYgnBusgbwgK.png (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: https://mrelay.p2pool.observer/m/monero.social/TdwwkZRUhcHTPhItvshfotYb.png (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
#nevent1q…px69

2026-10-08 02:53:41 GMT

- reply

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
#nevent1q…v96n

2026-10-08 02:49:56 GMT

- reply

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
#nevent1q…7zwe

2026-10-07 04:13:52 GMT

- reply

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

2026-10-07 04:13:10 GMT

- reply

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

2026-10-07 04:11:51 GMT

- reply

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

2026-10-07 04:10:07 GMT

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

2026-10-05 00:34:48 GMT

Plaintext E03: FROST Secure Two-Round Multisig with Luke Parker (kayabaNerve).
https://www.youtube.com/watch?v=SSl_WBgohPk

2026-10-01 03:48:01 GMT

- reply

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.
https://blossom.primal.net/17f274e123663118133140ed11e753722313f456ac18511e8a673c47656627bf.png
https://blossom.primal.net/db7826aca0d995b0798c537751c45daa0a48ea62b742f9f6230d62cf8c98b838.png
https://blossom.primal.net/9d7d4f49da28ba0a76a1c7a75e5f8a426b0a9bfa6c4b53582e4ce735866988d3.png
https://blossom.primal.net/49f6a425bcea56c9e2c646107a98b1dec68d2148eb3ad90560af2a95aff31d7a.png
https://blossom.primal.net/58898338b45da1f76c8c1e085225e7289398e67fbf710d0a286bee9b0be28cc6.png
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: https://mrelay.p2pool.observer/m/monero.social/aegJQTnYiWoiwUqahUTdjkPN.png (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: https://mrelay.p2pool.observer/m/monero.social/XfXqdmLKCYkFSqJrBLglvfhJ.png (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: https://mrelay.p2pool.observer/m/monero.social/CUGFPEpOKquQQCGJkoVHByQM.png (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: https://mrelay.p2pool.observer/m/monero.social/sPaYzhxriRWIiShryOZQoLeG.png (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: https://mrelay.p2pool.observer/m/monero.social/XfXqdmLKCYkFSqJrBLglvfhJ.png (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: https://mrelay.p2pool.observer/m/monero.social/RFoBnDUkiflymxjjeHaxIpGz.png (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
#nevent1q…0vqm

2026-10-01 03:24:00 GMT

- reply

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
#nevent1q…v4ak

2026-10-01 03:14:34 GMT

- reply

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
#nevent1q…j9el

2026-09-30 03:48:16 GMT

- reply

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

2026-09-30 03:46:50 GMT

- reply

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

2026-09-30 03:42:16 GMT

- reply

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

2026-09-30 03:40:36 GMT

- reply

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

2026-09-30 03:38:56 GMT

Monero Research Lab Meeting - Wed 30 September 2026, 17:00 UTChttps://github.com/monero-project/meta/issues/1466 https://blossom.primal.net/f0c475586d73608c5998e05fbd6cf47f2acaac62948b9abd4d85d5fe75e2ea15.png

2026-09-24 15:23:00 GMT

- reply

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
#nevent1q…26wd

2026-09-24 15:17:27 GMT

- reply

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
#nevent1q…n496

2026-09-23 03:12:04 GMT

- reply

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

2026-09-23 03:10:19 GMT

- reply

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

2026-09-23 03:08:03 GMT

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

2026-09-17 03:55:35 GMT

- reply

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
#nevent1q…qugw

2026-09-17 03:31:46 GMT

- reply

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
#nevent1q…res7

2026-09-17 03:12:21 GMT

- reply

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
#nevent1q…7j3f

2026-09-17 03:07:08 GMT

- reply

dnvie (lead author) presented MoneroVis, an open-source visual analytics tool for multi-level Monero exploration (live mempool/blocks down to ring structures and monetary flows). https://x.com/moneroism/status/2100128874478567615
It visualizes existing probabilistic heuristic cues without new tracing algorithms or calibrated confidence scores. Live instance: https://monerovis.com. Code: https://github.com/dnvie/MoneroVis
Discussion covered fixed ring size 16 for v16 txs, the WannaCry case study, notable ring-member/coinbase highlighting, P2Pool sweep detection, a suggested CCS-hack postmortem case (https://moonstoneresearch.com/2023/11/03/Postmortem-of-Monero-CCS-Hack), historical max ring sizes, the SoK on deanonymization assumptions (https://moneroresearch.info/97).
rucknium: 3. Tehrani & Tovanich (2026) "MoneroVis: Visual Analytics for Exploration and Traceability in a Privacy-Preserving Blockchain" (https://dnvie.com/docs/MoneroVis.pdf)
rucknium: With us today we have Daniel Nikbakht Tehrani ( dnvie ), the lead author of the paper. Welcome!
dnvie: 👋
rucknium: dnvie: Do you want to briefly summarize the paper and tool?
dnvie: At a high level, MoneroVis is an open-source visual analytics tool we built to help explore and inspect Monero transactions across different levels of detail, from live mempool and block monitoring down to ring structures and monetary flows. It is worth stressing that we do not introduce any new heuristics or tracing algorithms here. Instead, the core contribution is taking known, existing traceability heuristics from prior research and combining them into an interactive visual environment. That allows users to explore rings under uncertainty, visually connecting signals like ring member age distributions or implementation bugs like the 10-block bug. It's 2 most notable features are the "decoy map", which show the reuse of outputs as ring members across the blockchain, as well as the automated poisoned output tracing
rucknium: A live instance is running at https://monerovis.com . Open source code is at https://github.com/dnvie/MoneroVis
dnvie: Looking ahead regarding FCMP++, it is important to note that we know ring-based heuristics will become obsolete. So while MoneroVis is useful today for inspecting and auditing the current protocol, we know that, at least in its current state, most of its features will not be usable after the upgrade
dnvie: Also, for a brief description of the main features, please refer to the README in the github repo: https://github.com/dnvie/MoneroVis/blob/main/README.md
rucknium: I want to caution anyone who wants to look at their own transactions that monerovis.com could be logging queries (but we hope it doesn't 😉). So be careful of privacy. Interested users can run their own instance of MoneroVis on their own machines for better privacy.
dnvie: Yes, in theory i could see all of the data, so please self host. Also, it is currently running on a rapsberry pi, so I am unsure how many concurrent users it can even support
articmine: Can the user control the ring size
jeffro256: No, not since many upgrades go
jeffro256: *ago
jeffro256: Ring size for all v16 txs is fixed at 16
ack-j: dnvie: were you able to use monerovis to identify any recent true spends?
articmine: I mean on Monero Vis
rucknium: dnvie: It seemed pretty fast, even over a Tor connection. I admire that because my data webapps are usually slow 😅
dnvie: ack-j: We only used the WannaCry funds as a case study so far
dnvie: articmine: What exactly do you mean with controlling ring size on MoneroVis?
jeffro256: This is a cool visualization, and I like the "notable ring member" notices, although marking every coinbase member will probbly result in a lot of false negatives
articmine: Simulation of different ring size for impact on the accuracy of heruistics
sech1: Cool tool. Did you implement P2Pool miner sweep detection? https://p2pool.observer/transaction-lookup
jpk68: jeffro256: Do you still have a link to the transaction with the highest recorded ring size?
sech1: Although it will require real-time tracking of P2Pool chains
jpk68: I lost the TXID, apologies :)
rucknium: It could be interesting to also reproduce analysis of a more recent case (which has the more advanced Monero protocol features): https://moonstoneresearch.com/2023/11/03/Postmortem-of-Monero-CCS-Hack
articmine: I see use outside of Monero for MoneroVis
dnvie: sech1: No
rucknium: And that analysis would end up with "the trail runs cold". But at least it uses the output merging heuristic in the beginning.
dnvie: rucknium: Interesting, I will take a look at this
dnvie: articmine: No, you can only use “live” blockchain data, no simulations
jeffro256: jpk68: Uh I should yeah. Gimme a sec
rucknium: jeffro256: So you are about to break MoneroVis :D
jeffro256: Max observed total ring members in any one transaction on the main chain is 4524 in f901cb282db0104f33d884fc01f751cd0846a3c20dc35c37ed47f6bb1d1f8af0. Max observed ring size in any one ring on the main chain is 4501 in 5e75b4596c234ad17d34c44c3f07da508afb985748b3066bbfe2923cedb0b81a.
rucknium: IMHO, you could add this to the README and monerovis.com. It discusses caveats to blockchain analysis, including for Monero: Deuber, D., Ronge, V., & Rueckert, C. (2022). "SoK: Assumptions Underlying Cryptocurrency Deanonymizations." Proceedings on Privacy Enhancing Technologies, 2022(3). (https://moneroresearch.info/97)
rucknium: I assume the paper is in its final state, so it cannot be edited at this point.
dnvie: rucknium: Will do
dnvie: rucknium: correct
jpk68: jeffro256: Browser tab with that open is using 790 MiB of RAM ;)
rucknium: You say
rucknium: > MoneroVis visualizes multiple probabilistic heuristic cues without assigning calibrated confidence scores or asserting a true spent input, since ground-truth inputs and thus reliable false-positive rates are generally unavailable for real transactions. Instead, the value of the tool lies in supporting the exploration of money flows and reasoning under uncertainty.
rucknium: IMHO, that's not completely true. I've done it at least twice: 1) Discussion Note: Formula for Accuracy of Guessing Monero Real Spends Using Fungibility Defects (https://github.com/Rucknium/misc-research/blob/main/Monero-Fungibility-Defect-Classifier/pdf/classify-real-spend-with-fungibility-defects.pdf) 2) https://github.com/Rucknium/OSPEAD
rucknium: You don't need ground truth to estimate probabilities.
ack-j: dnvie: you may find this interesting, as I collected a lot of the same heuristics into a DB. The paper is also hard to find as it was never published :/
ack-j: https://github.com/ACK-J/Monero-Dataset-Pipeline/blob/main/Lord_of_the_Rings__An_Empirical_Analysis_of_Monero_s_Ring_Signature_Resilience_to_Artificially_Intelligent_Attacks.pdf
articmine: rucknium: This can be a highly controversial subject in Bitcoin.
articmine: In fact the reliability of these money flow heruistics is currently the subject of an appeal before the US Court of Appeals DC circuit
articmine: This is I consider this very valuable research
dnvie: rucknium: That’s a fair point, you’re right that you can estimate probabilities and model bounds without labeled ground truth. In the paper, we were speaking more from the practical design perspective of the visual interface. We chose not to assign confidence scores to ring members to avoid users treating them as definitive, especially when multiple heuristics overlap, but saying reliable rates are generally unavailable was definitely an overstatement on our part
dnvie: ack-j: Thanks for sharing!
rucknium: dnvie: I may give some followup questions and comments after the meeting if you don't mind.
dnvie: rucknium: Sure
rucknium: More questions and comments for dnvie for now?
articmine: I will wait for after the meeting
sgp_: thanks for calling them "poisoned outputs" not some other weird name
rucknium: Monero has multiple names for everything :D. Did you know that the Monero code refers to decoys as "fake-outs"?
rucknium: dnvie: Thanks for your work and for attending the meeting, dnvie !
dnvie: rucknium: Thanks for having me!
https://libera.monerologs.net/monero-research-lab/20260916#c708107
#nevent1q…jcfe

2026-09-16 00:18:35 GMT

- reply

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

2026-09-16 00:18:21 GMT

- reply

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

2026-09-16 00:16:25 GMT

- reply

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

2026-09-16 00:15:41 GMT

- reply

Second FCMP++ circuit review: CCS approval.

2026-09-16 00:14:13 GMT

- reply

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

2026-09-16 00:13:19 GMT

- reply

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

2026-09-16 00:08:37 GMT

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

2026-09-09 20:29:07 GMT

- reply

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
#nevent1q…9mxu

2026-09-09 20:25:19 GMT

- reply

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
#nevent1q…kalv

2026-09-09 20:19:30 GMT

- reply

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
#nevent1q…rgk6

2026-09-09 20:02:18 GMT

- reply

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
#nevent1q…808p

2026-09-08 18:56:58 GMT

- reply

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

2026-09-08 18:55:08 GMT

- reply

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

2026-09-08 18:53:53 GMT

- reply

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

2026-09-08 18:51:41 GMT

- reply

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

2026-09-08 18:48:36 GMT

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

2026-09-07 19:38:07 GMT

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

2026-09-03 02:11:05 GMT

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

2026-09-02 18:05:03 GMT

- reply

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
#nevent1q…8p6m

2026-09-02 18:01:34 GMT

- reply

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
#nevent1q…cu37

2026-09-02 17:48:03 GMT

- reply

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
#nevent1q…elvt

2026-09-02 17:20:33 GMT

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

2026-09-02 17:16:54 GMT

xmrack: @MagicGrants: set up an automated security review of monero PRs
https://github.com/xmrack/monero-review/issues
I have opus-5 scan a new pr from a queue every 30 minutes. Each time the pr’s hash changes it gets back inline for the queue.

2026-09-02 15:45:12 GMT

- reply

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

2026-09-02 15:43:40 GMT

- reply

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

2026-09-02 15:42:08 GMT

- reply

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

2026-09-02 15:39:45 GMT

Monero Research Lab Meeting - Wed 02 September 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1451 https://blossom.primal.net/b590687e93c28160dc43088d3cdef9352e1e4fcad1dd2597a21f8539dfca31cf.png

2026-08-26 19:34:53 GMT

- reply

6. Validating key images
https://github.com/monero-project/monero/pull/11155
https://github.com/monero-project/monero/pull/11152
selsta asked whether the next release should merge 11152 while landing 11155 on master. jeffro256 agreed (SGTM). jberman said both look fine. No further discussion.
https://libera.monerologs.net/monero-research-lab/20260826#c703895
#nevent1q…d80h

2026-08-26 19:29:43 GMT

- reply

v3 is expected to pull FCMP staging-branch changes plus latest master. Hot/cold remains the major lingering checklist item (checklist not yet updated). jeffro256 will finish responding to reports, then complete hot/cold.
https://libera.monerologs.net/monero-research-lab/20260826#c703889
DataHoarder: as mentioned before, I assume this also brings up the changes from the fcmp staging branch onto v3?
jberman: Hot/cold PR is the major lingering item (I haven't updated that checklist)
jberman: DataHoarder: yes, and latest master
DataHoarder:
jeffro256: I'm working on responding to some reports, and then I'll be on top of finishing hot/cold
#nevent1q…66dq

2026-08-26 19:24:52 GMT

- reply

CjS77 wants inclusion confirmed before building on them. jberman expects little resistance if the protocol is specced and usable, and would not block the consensus PR, but wants a concrete development path. UkoeHB: no strong objections; keep the basic-rule PR moving. Grease is not ready to spec a full PC protocol.
Still open: lock length (1 day vs 1 week; 3 days as a compromise; only one value can ship) and O(n) state per update. UkoeHB sketched a way to avoid O(n); Grease v1 VCOF aimed at the same problem, no guaranteed solve. tevador: O(n) is fine (~300 B/state); imperfect locks + working channels beat nothing.
rucknium: XMRChat is the obvious first use case; fiatdemise will read a writeup. Next: share this thread with Grease. A new paper with relative locks was floated (long wait); jberman would not wait 9 months to ship the lock.
https://libera.monerologs.net/monero-research-lab/20260826#c703846
UkoeHB: loop.ster oh perfect, doesn't that directly solve https://github.com/monero-project/research-lab/issues/161#issuecomment-5396778447 ? Not sure why CjS77 mentioned it as a problem.
loop.ster: As I mentioned in the PR comment, I suspected it might, but I hadn't thought it through. So it was just a gut feel, and so I didn't want to assert that the issue was resolved, but kinda left the idea out there to be explored. (I'm CjS77 on GH)
UkoeHB: loop.ster ah got it, so the VCOF exploration was for an older version of Greese. Practically speaking would applications really need to adopt nanotransactions like you describe? I'd think a minor level of trust would allow payment in advance for aggregations of those payments.
rucknium: 4. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161).
jberman: u/CjS77 expressed hesitation in building with them until the feature would be confirmed included in Monero
jberman: > I guess I'd like to take the temperature on the level of support before committing to anything.
jeffro256: What about its viability as it relates to Grease?
jberman: I responded that I have a hard time seeing significant resistance to the feature if the protocol is fully specced + there's a developemnt path to utilizing the feature
jberman: https://github.com/monero-project/research-lab/issues/161#issuecomment-5396778447
jberman: Sounds like it would be a major change to their protocol
tevador: Classic chicken-egg, but shipping the consensus code for the lock is probably way less work than designing the actual PC protocol.
jberman: If someone was actually interested in designing the actual PC protocol, then I think it would make sense to seek funding for that design, rather than funding for a protocol that relies on trust
jberman: Doesn't make sense to me that they wouldn't be interested in that work personally
jberman: I mean, I guess it's not a major risk to include that change to consensus either way, but it would be nice to have a concrete path to using it established first
tevador: One thing that's still TBD is the lock length since we can only ship one value. 1 week would have some advantages for PCs compared to 1 day, but maybe 3 days is a good compromise.
rucknium: Does anyone have a way to contact fiatdemise ? IMHO, XMRChat.com is the most obvious first use case for payment channels. Maybe that could get some momentum behind the payment channels idea.
rucknium: Maybe I will try to email the XMRChat support email address.
jberman: Another thing u/CjS77 raised in that issue is the issue of requiring O(n) state growth for channel updates, and UkoeHB sketched a potential way to avoid it? I know bitcoin would need a consensus change to achieve it on their end (eltoo), so seems like another open area to consider
fiatdemise: Hi, I'm not familiar with payment channels or their benefit, but I'll take a look at an email with more info.
UkoeHB: I sketched some requirements for one way to avoid it, and Cjs77 pointed out the speculative/experimental VCOF from greese v1 aims at the same problem. But no guaranteed solve.
rucknium: fiatdemise: Hi! If users are getting frustrated with the 10 block lock, payment channels could solve that, at the cost of more complexity. I will email you later.
tevador: I think O(n) channels are acceptable. One state is maybe 300 bytes?
rucknium: The BTC Lightning Network is based on aggregating many payment channels
jberman: > Not an issue for moderately active channels (n < 1000), but for some of the applications that I would love to see for channels that involve many thousands of updates (fine-grained streaming content for example)
jberman: I think that was a solid point
tevador: Let's aim for incremental improvements
UkoeHB: Don't we need a perfect design for payment channels to be useful
rucknium: Anyone aware of BTC Lightning being used for fine-grained streaming content?
UkoeHB: Don't think*
tevador: It's better to have non-perfect relative locks with non-perfect (but working) payment channels than nothing.
jberman: point remains it would be nice to have a fully developed protocol prior to shipping a consensus change that has these sort of kinks ironed out and understood (and provably functioning payment channels)
tevador: Then we're back to the chicken egg problem
rbrunner: Didn't tevador post a sketch of such a protocol? And if yes, isn't that at least a starting point?
jberman: Ya, I really don't think u/CjS77 would have an easier time getting funding after this change is merged versus before, so I really don't think this is actually a chicken egg problem
rucknium: More discussion on relative locks for now?
jberman: In any case, I don't think the change needs to be held back. I think it's ok. At the same time, I'd like to see a concrete development path for it
UkoeHB: Re: relative locks I propose we keep pushing forward with PR to add the basic rule. So far there seem no strong/direct objections, just jberman preferring a protocol be more fleshed out.
UkoeHB: It seems the Greese team isn't prepare to flesh that out, so idk if any progress will be made on that front.
jberman: we can share this convo with them and see what happens on that front
rucknium: Maybe one of the authors of those #Monero payment channel papers can write a new paper with relative locks :)
rucknium: I mean, maybe they could be contacted. Could be worth a shot. But probably a 9 month wait on something like that.
jberman: ya I wouldn't veto this change pending a 9 month wait, I personally do think it's ok
UkoeHB: If we are 9mo out from hf, that would be good timing for a paper for someone to pick up and implement.
#nevent1q…csu2

2026-08-26 19:01:39 GMT

- reply

jberman: On Research Task audits: Request for quotes on circuits + gadget + fcmp-plus-plus lib has gone out, we've gotten some responses but nothing major to report yet
On tasks: next major item is hot/cold wallet integration jeffro256 mentioned above, in the final cycles now on that task
Here's the latest upstream PR for FCMP++ integration: github.com/monero-project/monero/pull/10361
https://libera.monerologs.net/monero-research-lab/20260826#c703833
#nevent1q…xtga

2026-08-26 15:34:32 GMT

- reply

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

2026-08-26 15:32:17 GMT

- reply

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

2026-08-26 15:30:29 GMT

- reply

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
https://x.com/MoneroResearchL/status/2090157851154972695
nevent1qqs8f890a0klxx70ksrk3fs8ae8a8uu3h0n3zkyppjay2nn43383tqsrdk0m5

2026-08-26 15:27:56 GMT

Monero Research Lab Meeting - Wed 26 August 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1448
https://blossom.primal.net/536971358c51fda6ce5164ce0f9c73bd549e3b15f9e8e0b2b4e12ef617bb296e.png

2026-08-19 19:40:55 GMT

- reply

sech1: I created https://github.com/monero-project/monero/pull/11102 to make life easier for P2Pool when handling these transactions
This item can be removed from agenda for the next meeting, because I'll be working on general FCMP++/Carrot support for P2Pool, and zero-fee transaction support will be added after all that.
https://libera.monerologs.net/monero-research-lab/20260819#c702362
#nevent1q…2hu5

2026-08-19 19:37:11 GMT

- reply

jberman and jeffro256 aim to include the hot/cold wallet changes in beta v3 (desired order: hot/cold first, then rebase on latest master). The changes are significant for the wallet and are a fork requirement. jberman is re-reviewing the PR and hopes to have it ready by next week. rucknium has shut down his tx spammers and returned nodes to regular testnet. Concrete testing of new wallet/daemon software before the fork would be valuable; an initial fork that only separates networks (keeping current rules) could allow spam without affecting current testnet. Cuprate could also run on stressnet during that period.jberman: Re: beta stressnet. Discussed with jeffro256 and we're going to aim to have the hot/cold wallet changes in for beta v3 as well. So desired order of operations is hot/cold wallet changes then rebase on top of latest master
https://libera.monerologs.net/monero-research-lab/20260819#c702343
jberman: The hot/cold wallet changes bring a pretty significant change to the wallet, and I think it'll be good to have it sorted out in that order
rucknium: I have shut down all my tx spammers and switched my nodes back to regular testnet.
jberman: So right now working on my re-review of the hot/cold wallet PR and hopefully we'll have that ready by next week. I know I said hoping by next week last week, but hot/cold wallet stuff does make sense to get in first for reasons above (which I wasn't considering when I said that)
jberman: And making sure hot/cold wallets are ready for the fork is obviously a requirement for the fork anyway
jberman: One thing I've been thinking that would be nice is to have some good concrete testing of the new wallet/daemon software before the fork. We don't need to spam during that period (that would spam current testnet), but a concerted effort at testing during that period would be nice
jberman: Maybe we'd want to consider an initial fork from current testnet that just separates networks, but maintain current rules pre-fork, that would allow people to spam
rucknium: jberman: You could have cuprate on stressnet for that time, too.
#nevent1q…d8h9

2026-08-19 19:31:01 GMT

- reply

jberman: I just commented on the original issue here: https://github.com/monero-project/research-lab/issues/161#issuecomment-5345884915
I think it could potentially help strengthen the case for them if the Grease people want to run with that primitive
https://libera.monerologs.net/monero-research-lab/20260819#c702340
#nevent1q…qfhy

2026-08-19 19:24:03 GMT

- reply

jberman is re-reviewing jeffro256’s hot/cold wallet PR (a dependency for UkoeHB’s multisig work); it is very close. An RFQ is going out for the gadgets + circuit + fcmp-plus-plus audit. Licensing discussion for mx25519 continues in https://github.com/monero-project/monero/pull/10964; tevador proposed making the core API + portable implementation permissively licensed and the fast assembly backends copyleft. Polyseed remains LGPL unless tevador relicenses. Discussion covered a possible in-binary license text display mechanism, CoC implications, the GPLv3 readline dependency (tobtoht suggested replacing it with linenoise), and exposure via wallet API for smartphone apps. Even without mx25519/Polyseed the project is out of compliance with some BSD-3 terms.
https://libera.monerologs.net/monero-research-lab/20260819#c702305
jberman: Next major item: Re-reviewing jeffro256's hot/cold wallet PR now, which is also currently a dependency for UkoeHB 's multisig work. Hot/Cold wallet stuff is very close I think
jberman: RFQ is going out for gadgets + circuit + fcmp-plus-plus audit, nothing to report on there yet
jeffro256: Licensing discussion still ongoing in https://github.com/monero-project/monero/pull/10964 for mx25519. Tevador proposed an interesting solution: effectively make the core API+portable impl licensed permissively, and the fast assembly backends (where the magic happens) copyleft
jeffro256: I was hoping that he'd be here today, oh well
rucknium: Thanks, jberman and jeffro256 . More on this topic?
rbrunner: That "trick" probably won't extend to the much simpler Polyseed library?
jeffro256: I was wondering if it would be worth it to work on a quick license library to fetch license text to display in-binary for applicable licenses
jeffro256: Unless tevador chooses to re-license, then Polyseed remains under LGPL
tobtoht: jeffro256: How would that work?
slowbeardigger: What about, relicensing the mx25519 to MPL-2.0 pls split the library?
slowbeardigger: like BSD-3 the core + C portable implementation, MPL-2.0 the assembly backends
slowbeardigger: Compilation flags included on the fast assembly
slowbeardigger: I think Trevador said he likes a way like that
tobtoht: That's exactly the solution tevador suggested.
slowbeardigger: yeah
slowbeardigger: if you ask me, that seems to be the “easiest” way
articmine: The licensing issue raisees many questions for dicussion.
slowbeardigger: Gets the thing done in a couple of commits, and not a lot of drama
slowbeardigger: less friction way imo
articmine: I am just looking at the Github
jeffro256: tobtoht: It would look like a license command in daemon/wallet CLI/wallet RPC etc which pulls text from an in-binary array, which is inserted during build time based on a maintained license file
jeffro256: So when we add a new dependency which requires distrubuting source code information alongside the binary, a contribuor would append applicable info to the license file, which gets added into the binary during build time
jpk68: Not sure there's much point to the licensing section of the CoC if it can just be ignored
jeffro256: Even without mx25519/Polyseed we should probably do this because we are out of compliance with some BSD-3 licensing
tobtoht: Our biggest licensing issue right now is our GPLv3'd readline dependency
tobtoht: I suggested replacing it with linenoise from Redis
jpk68: It would also be a drastic reduction in LoC for that functionality
rucknium: FWIW, R and python have a license text that can be printed with license().
rbrunner: Would this license content mechanism be available to smartphone wallet apps as well?
tobtoht: jpk68: Yep, would also drop ncurses.
tobtoht: rbrunner: We could expose it in wallet api?
rbrunner: Sounds reasonable.
#nevent1q…ujhr

2026-08-17 22:58:06 GMT

- reply

PoW-Admitted Zero-Fee Transactions for P2Pool.
https://gist.github.com/SChernykh/aae5b2d414095e742437134ab20d4353
nevent1qqsfz4ncfl6hd9sprzw4r4s8v892dcmpjyhrlnmxun3ngxlah8lye5qpasn6h

2026-08-17 22:56:27 GMT

- reply

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

2026-08-17 22:54:00 GMT

- reply

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

2026-08-17 22:52:27 GMT

- reply

4. 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/
nevent1qqsdhkvqtuuy56tsncnjkscl5gtamnknskjph6upvmf2wmn4cv0rttq3nm5vk

2026-08-17 22:51:23 GMT

- reply

3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak).
https://github.com/jeffro256/carrot/issues/10
nevent1qqsqmns392rqucpz5mzsjwwj64knvgly4xfzj35ddmmgmhq3vle6d2sjkhs8a

2026-08-17 22:44:31 GMT

Monero Research Lab Meeting - Wed 19 August 2026, 17:00 UTC
https://github.com/monero-project/meta/issues/1443
https://blossom.primal.net/073c174fd199c5f5fab360bc09c6d3f3dfec15c16c287a7092db0b943fab1a22.png

2026-08-17 18:43:56 GMT

MAGIC Grants recently had Trail Of Bits (https://www.trailofbits.com/), a leading cybersecurity and research firm, audit certain cryptography for Monero's forthcoming FCMP++ upgrade. This upgrade will substantially increase the privacy of Monero transactions.
Read more: https://magicgrants.org/2026/08/17/Monero-FCMP-Cryptography-Implementation-ToB

2026-08-12 20:10:15 GMT

8. PoW-Admitted Zero-Fee Transactions for P2Pool (gist.github.com/SChernykh/aae5b2d414095e742437134ab20d4353).
sech1 presented a proposal for zero-fee transactions that require a cryptographically bound PoW solution, eliminating the usual spam risks. The main goals are miner payout consolidations and stronger incentives to mine on P2Pool. These transactions would be broadcast only over the P2Pool network layer; monerod would never accept or relay them and would see them solely inside mined blocks. Discussion focused on the resulting block-propagation delay (a 128-input FCMP++ consolidation can be ~180 KB), which is mitigated by P2Pool’s own distribution to all its nodes (limiting the number of hops across the wider Monero network to roughly 1-2). jeffro256 suggested an alternative that uses side FCMPs to prove inputs belong to the set of P2Pool outputs (this would leak that the transaction is a consolidation). DataHoarder is already exploring related aggregation ideas. boog900’s proposal for normal nodes to fast-relay PoW-valid blocks (https://github.com/seraphis-migration/monero/issues/454) was noted as complementary. Preferences ranked a dedicated miner-consolidation transaction type highest, followed by the PoW-admitted zero-fee approach, then ordinary fee-paying consolidations. The specialized type is unlikely for the next hard fork, so sech1 is advancing the PoW design in draft/concept form; many edge cases remain (for example P2Pool must track key images independently of monerod’s mempool). The item will stay on the agenda.
rucknium: 8. PoW-Admitted Zero-Fee Transactions for P2Pool (gist.github.com/SChernykh/aae5b2d414095e742437134ab20d4353).
rucknium: sech1
sech1: In a few words: I think I found a way to introduce 0-fee transactions without their downsides (tx spam), by requiring PoW for them (PoW solutions are cryptographically bound to each tx). Read the link above
sech1: The main purpose is to use them for miner payout consolidations
sech1: and to add more incentives to mine with P2Pool
rucknium: Are these txs broadcast throughout the network, or only accepted in the txpool of nodes that have a p2pool miner attached?
sech1: They are broadcast through P2Pool network layer, not Monero
sech1: P2Pool only sends mined blocks to monerod (blocks with 0-fee transactions, if any)
rucknium: OK. I read the first two sections, but I did not remember seeing a clear statement on that.
sech1: monerod doesn't accept/relay such transactions, so it's the only way
rucknium: Doesn't that slow down block propagation because those txs need to be requested instead of pure fluffy blocks propagation?
sech1: hmm, it does
sech1: By how much - it's another question that will need testing
jeffro256: For p2pool consolidations, you can also do it with out PoW by having the p2pool nodes build a set of all p2pool outputs, then attaching FCMPs on the side of the tx that prove the inputs are in the set of p2pool outputs. This, of course, leaks that the tx is a consolidation tx.
sech1: Note that 0-fee transactions as described are already possible already today, just no one does it. P2Pool proposal just makes it more viable to use.
sech1: jeffro256 I think DataHoarder is looking into this
tevador: The consolidation tx may be quite large, 128-input FCMP++ is ~180 KB.
DataHoarder: I am and reimplementing some stuff yes. Even aggregation of outputs (but that is more complex)
sech1: Yes, consolidation tx are large, but they will happen anyway because P2Pool miners do need to use their mined coins
sech1: The proposal just exchanges monetary fee with a PoW fee (electricity, time spent)
tevador: My point is that each node at each hop will need to download 180 KB from the sending peer, slowing block propagation. Maybe it's acceptable.
rucknium: You could have all nodes accept these txs so that block propagation would not be delayed. But that's risky because a flaw in the p2pool implementation side could open the door to malicious spamming throughout the network.
sech1: Don't forget that P2Pool submits mined blocks to all its nodes, and 0-fee tx will also be submitted to all P2Pool nodes at the same time
sech1: which limits the number of hops to the entire Monero network to 1-2
sech1: Because all P2Pool nodes will mine the same 0-fee tx once its broadcasted (through P2Pool network)
rucknium: Mining pools could attach p2pool to their nodes that produce block templates to speed up propagation where it matters the most, but that would require action by the operators of the mining pools. And it could leave out solo miners who don't do that.
sech1: IIRC supportxmr runs P2Pool instances on their servers
sech1: It's in the interest of mining pools to receive P2Pool blocks faster, and they can just run a node - they don't have to diverge hashrate to it
sech1: solo miners can do the same, if they're informed about it
boog900: I recently made an issue for making it so normal nodes can fast relay blocks like p2pool: https://github.com/seraphis-migration/monero/issues/454
jberman: rucknium: Relevant: boog900's idea to relay blocks that pass PoW before doing validation would help, so nodes can at least start doing the work in parallel (but yes would still need to request and verify said txs) https://github.com/seraphis-migration/monero/issues/454
sech1: Yes, P2Pool implementation must be rock solid in terms of verifying that a specific PoW solution does bind to a specific transaction - but all the machinery is already in P2Pool (merge mining) and it's battle tested
jberman: ha, jinx
sech1: Monero relaying PoW-checked blocks will not be faster than P2Pool unless it also enables RandomX dataset (+2 GB on RAM requirements) by default
sech1: P2Pool does it, Monero daemon is more restricted
slowbeardigger: i think i have the right idea…
sech1: It can be enabled with an environment variable, by it's off by default
sech1: *but
boog900: It should still make the network as a whole faster rather than just p2pool doing it
sech1: true
boog900: And it removes the requirement of running p2pool to get fast blocks, for example stressnet has no p2pool at all
sech1: P2Pool does bring the block relay to only 1-2 hops on the scale of the whole network, already, so the improvement will be marginal
sech1: Because each Monero node is either connected to P2Pool, or 1-2 hops away from a P2Pool-connected node
sech1: and P2Pool relays all Monero blocks, not just its own
sech1: but we digress from the 0-fee PoW transactions topic
boog900: Its an easy change to allow blocks to be invalid if the pow is valid
sech1: I don't argue that, I'm just saying the improvement will be marginal (but there will be an improvement)
rucknium: More discussion on this? I will keep it on the agenda next time.
jberman: 1-2 hops could be >5-10s if the block has 128-in txs fwiw
sech1: also true, especially for FCMP++
sech1: then it's not so marginal improvement, I'm for https://github.com/seraphis-migration/monero/issues/454
boog900: I would rather specific miner consolidation txs rather than 0 fee txs
sech1: Same, but there were strong arguments against a specialized tx type
sech1: so it was decided not to introduce them in the next hardfork
sech1: I think (?)
sech1: My preference is: (1) miner consolidation tx type (2) PoW-admitted 0-fee tx
sech1: and (3) regular consolidation tx paying regular fee - the worst for P2Pool adoption
boog900: I think 2 can be done with a hope to eventually get to 1
boog900: I don't think 1 can be done for the next fork
sech1: which is why I started woring on (2). Right now it's in draft/concept phase only, the actual implementation will take a lot of work due to many edge cases there (this is why that document is so long)
rucknium: We can end the meeting here. Thanks everyone.
sech1: for example, P2Pool will need to track key images, duplicating some mempool functionality - because the 0-fee tx is not a part of monerod's mempool, and there can be conflicting transactions there
https://libera.monerologs.net/monero-research-lab/20260812#c700269
#nevent1q…wcyx

2026-08-12 20:03:12 GMT

7. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).
There was clear demand for a fresh chain. jberman agreed that jeffro256’s suggestion to raise the minimum penalty fee zone to the current stressnet’s maximum block size is reasonable, allowing larger blocks immediately. With boog’s green light on https://github.com/seraphis-migration/monero/pull/450, all code needed for a beta v3 is now ready. jberman plans to have the latest master on the beta stressnet branch plus a new v3 release ready next week, and suggested possibly reusing the v2 logic that lets nodes automatically pop back to the prior fork height. He will turn https://github.com/seraphis-migration/monero/pull/415 into the v3 checklist so progress can be tracked. rucknium said he may halt his spammers on the current stressnet. vtnerd noted that his SSL patch needs another rebase; jberman advised waiting until master is fully merged to avoid further conflicts.
rucknium: 7. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).
rucknium: The people cry out for a new fork from testnet :D
slowbeardigger: rucknium: indeed
slowbeardigger: I can’t wait xd
jberman: Yes looks like people want a fresh chain, and jeffro256 's idea to raise the min penalty fee zone to current stressnet's max block size to allow for larger blocks right away seems reasonable to me
jeffro256: yay
jberman: With boog's green light on this PR https://github.com/seraphis-migration/monero/pull/450 , I think now we should be good to have all code for a beta v3 ready
jberman: So will aim for next week to have latest master on the beta stressnet branch + a new v3 ready to go
jberman: jeffro256 we could maybe reuse that logic from v2 to have nodes auto pop back to the prior fork height
rucknium: I may halt my spammers on the current stressnet.
jberman: I can turn this into the v3 checklist and people can follow along there as we knock out the tasks: https://github.com/seraphis-migration/monero/pull/415
vtnerd: crap my ssl patch needs another rebase, adding that to my list this week
jberman: I think maybe wait til we have all of master in to avoid another round of conflicts
vtnerd: ok
https://libera.monerologs.net/monero-research-lab/20260812#c700252
#nevent1q…w6xw

2026-08-12 19:59:40 GMT

6. Shi, Zhang, Ge, Lan, Zhang, & Wang (2026) "Deanonymizing Monero Transactions in Tor Network." (https://arxiv.org/abs/2607.07062)
vtnerd confirmed the Dandelion++ privacy leak remains on his to-do list along with hardening of timed-sync message handling against timing analysis. rucknium noted that last meeting boog900 had suggested reviving https://github.com/monero-project/monero/pull/9295 ("Fix embargo timeout in dandelion++") and reported that he has begun writing monerosim code to measure the tx-relay protocol’s resistance to spy nodes, with a possible comparison of the network with and without that PR. He will start simulations on tx-relay v1 because v2 deployment still appears further off. jberman reported that boog900 has reviewed the latest tx-relay v2 changes in https://github.com/seraphis-migration/monero/pull/450 and that this review provides a green light to include those changes for beta testing. He also pointed to https://github.com/monero-project/monero/pull/11048 as an additional helpful fix that should land in the next release. rucknium said that the planned simulation analysis will need to address statistical noise across different seeds in order to isolate genuine privacy differences.
rucknium: 6. Shi, Zhang, Ge, Lan, Zhang, & Wang (2026) "Deanonymizing Monero Transactions in Tor Network." (https://arxiv.org/abs/2607.07062)
rucknium: In his update, vtnerd said the Dandelion++ privacy leak was on his to-do list. > vtnerd: me: still need to work on a bug for selsta, and the d++ privacy leak discussed last week
rucknium: Last meeting, boog900 suggested that discussion of this PR be revived: https://github.com/monero-project/monero/pull/9295 "Fix embargo timeout in dandelion++"
vtnerd: and possible hardening of when certain messages can be sent, that was specifically used as a vector to run timing analysis
rucknium: I've started to write some code that can analyze the resistance of the tx relay protocol to spy nodes, using monerosim. I had in mind possibly doing a comparison test with and without PR #9295
rucknium: I'm not sure if I should run the simulations with tx relay v1 or v2. jberman or boog900 , do you have any opinions or info on when tx relay v2 might be deployed to mainnet?
jberman: boog900 reviewed the latest changes to tx relay v2 here: https://github.com/seraphis-migration/monero/pull/450
rucknium: In theory, there shouldn't be a big difference in the privacy of v1 and v2, but I would want to test what's most reasonable.
jberman: I think we will want to get that tested in beta, as testing uncovered the issues that PR solved (including with a change to the p2p messaging protocol)
jberman: I was going to raise this in discussion of stressnet, but with that review, I think that gives the green light for including those changes in tx relay v2 and moving forward with them for beta
rucknium: Thanks for the info. I think I will start with v1 because deployment of v2 seems to be a little further in the future.
rucknium: More discussion of this item?
jberman: boog900 also raised the point that this PR should help as well: https://github.com/monero-project/monero/pull/11048
jberman: which should land in next release (I'd figure it's maximally helpful when the whole network is running it, though)
sech1: from the description, it does help
rucknium: By the way, the simulation analysis is going to have to handle some interesting statistical issues to separate the noise of different simulation seeds from actual true differences in privacy levels of any proposed change. I will look into it myself, but input from others is appreciated.
https://libera.monerologs.net/monero-research-lab/20260812#c700236
#nevent1q…pg7y

2026-08-12 19:54:14 GMT

rucknium: 5. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161).
rucknium: Last we left this, koe said: rucknium: > < UkoeHB > I think we should get a prod-oriented PR for the change and aim further discussion at that.
rucknium: Do we have a prod-oriented PR for relative locks?
tevador: This PR needs a review: https://github.com/seraphis-migration/monero/pull/445
rucknium: UkoeHB: Any comments on relative locks for now?
UkoeHB: no, I will add review for 445 to my list
https://libera.monerologs.net/monero-research-lab/20260812#c700227
#nevent1q…as24

2026-08-12 19:50:56 GMT

4. 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).
jberman reported that the Rust FFI PR has been merged into upstream master and that the next item on the FCMP++ integration list is monero-project/monero #10360, the final PR from the Phase 1 audit. For Phases 2 and 3 he preferred continuing internal reviews and merges, with audits to follow once the code is fully in (or Phase 2 audited after its code lands). jeffro256 updated the planner at https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html. The largest remaining Carrot-side blocker is the LGPL licensing of mx25519 (https://github.com/monero-project/monero/pull/10964). Discussion focused on LGPL section 6 compliance (providing a link to the release tag commit), possible monero-site changes, CoC compatibility, effects on downstream wallets and hardware-wallet integrations, the existence of at least one other LGPL dependency (polyseed), and the feasibility of a permissive reimplementation. tevador declined to relicense and stated that the practical restrictions are mild (primarily adding the license text to the release archive). Views ranged from accepting LGPL in order to move forward quickly to concerns about added complexity, technical debt and downstream burden. No consensus was reached; the licensing discussion was left open and suggested for the No Wallet Left Behind agenda or further GitHub comment. On the audit side, the Least Authority helioselene review is near completion while quotes are still needed for the remaining research-task audits.
jberman: The Rust FFI PR was merged into upstream master (hooray), next on the FCMP++ integration list is: https://github.com/monero-project/monero/pull/10360
jberman: That is the final PR from the Phase 1 FCMP++ integration audit
jeffro256: I have updated the planner here: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html
jeffro256: OOps that's already linked
jberman: For Phases 2 & 3, right now I'm thinking it would be best to just keep going reviewing on our end and merging code, and once all code is in we audit then (perhaps we get Phase 2 audited once all that code is in). I think that would be most efficient
jeffro256: Biggest blocker on the Carrot side seems to be licensing around mx25519: https://github.com/monero-project/monero/pull/10964. tevador has mx25519 licensed under LGPL, which has some restrictive terms.
jberman: No major update at the moment on the final Research Task audits. The Least Authority helioselene audit is very close to the finish line
jeffro256: There's some discussion around how exactly Monero will comply with the terms in section 6 of LGPL v3: https://github.com/monero-project/monero/pull/10964#issuecomment-5208353737. IDK if anyone has something to throw in here, because it doesn't seem to be going anywhere quickly...
jberman: And we still need quotes for divisors impl audit rd. 2 + fcmp-plus-plus lib audit
jpk68: jeffro256: It does seem like this would complicate things a fair bit, which would be quite inconvenient. Adopting LGPL dependencies, I mean
jpk68: The amount of complexity surrounding this upgrade is already pretty extreme
jpk68: Downstream users of Monero code would also be affected by this (i.e. wallet applications)
tevador: The "restriction" of LGPL § 6 would imply we would need to provide a link to the tag commit the release was built from. Which is hardly a restriction.
jpk68: tevador: You mentioned that you didn't want to relicense your code after companies made proprietary forks of RandomX code.
tevador: Example: github.com/monero-project/monero/tree/v0.18.5.1
jeffro256: Yeah, that does involve some changes to monero-site, though.
jpk68: I'm wondering how the same concern applies to general cryptography code, rather than PoW
vtnerd: the primary objective of the lgpl is to force changes to mx25519 to be made public … ?
jpk68: Yes, but how is that practically relevant here? I can see how it is for RandomX
tevador: The exactly same thing applies to a Curve25519 library. If someone makes optimizations, we want to be able to upstream them.
vtnerd: I guess a wallet could be made faster in secret, similar to the issue in randomX
slowbeardigger: In xmrpay-carrot I already use a BSD-3 Rust implementation based on curve25519-dalek that matches the upstream CARROT vectors.
slowbeardigger: It only covers the receiver side CARROT operation for now, not the full mx25519 API.
slowbeardigger: would a permissively licensed rust implementation be useful, or does Monero specifically need C/C++?
vtnerd: c/c++ is more useful to the project I think, but opinions may differ
tevador: I'm pretty sure mx25519 is faster than curve25519-dalek
tevador: But both are usable for a wallet implementation
jeffro256: Espeially after considering Rust FFI
jeffro256: *Especially
slowbeardigger: hmmmm
slowbeardigger: what about a small portable BSD-3 C/C++ implementation be useful as a starting point if it matches the full unclamped API and existing vectors, or would optimized amd64/arm64 backends be required from the start?
slowbeardigger: just wondering if I can be of any help
vtnerd: this is assuming we are rejecting lgpl for some reason, it doesn’t seem to be a clear consensus on that
jeffro256: If you can get a portable implementation as fast as the amd64x version, I'd be impressed
tevador: A portable permissively licensed implementation could be made quite easily from the ref10 public domain code. But it's quite slow.
vtnerd: every wallet is open source already, if Im not mistaken
tevador: LGPL is open source.
slowbeardigger: jeffro256: I’ll try my best
vtnerd: I meant a wallet trying to use mx25519 but closed source somehow. I’m just not seeing any reason to worry about lgpl but maybe Im missing something
tobtoht: LGPL § 6 is not the only restriction and its restrictions would apply to all downstream projects, not just Monero.
tobtoht: LGPL is incompatible with the CoC: "All contributions to the project source code ("patches") MUST use the same license as the project."
jpk68: This is my point, we have already had enough trouble trying to get, for example, hardware wallet companies to integrate Monero
jpk68: Making licensing matters more complicated is shooting ourselves in the foot
slowbeardigger: I’m not assuming LGPL will be rejected. I’ll treat this as a small benchmark experiment first, compare it against the portable and amd64x implementations, and only suggest it if the result is actually useful…
slowbeardigger: I’ll start working on it
tevador: The CoC is clearly meant for other cases, like someone submitting a random patch under GPL.
tevador: AFAIK we already have at least one LGPL dependency
jpk68: Also, the LGPL wouldn't prevent proprietary freeloading, since they could link dynamically
jpk68: IIRC the only "copyleft" library we use currently is ZeroMQ, which is MPL
jpk68: That's somewhat less restrictive compared to LGPL
tobtoht: "The CoC is clearly meant for other cases" Also, the LGPL wouldn't prevent proprietary freeloading, since they could link dynamically
jeffro256: It would prevent modifying mx25519 itself, and not publishing the modifications, which is the point
rucknium: More discussion on this issue?
jeffro256: Ideally, we should figure this out soon, because it is a blocker for Carrot and Polyseed support
rucknium: Can the licensing discussion be moved to No Wallet Left Behind meetings or should it stay here for next week? Or moved back to GitHub?
jberman: tevador: do you see yourself budging on this issue and relicensing?
tobtoht: I will honor a vote
jeffro256: tobtoht: Since we have maintainers and approval processes, it is always at our discretition to block the changes that are superfulously adding non-permissive licensing for their own sake. I don't believe that Polyseed and mx25519 are those cases.
jeffro256: We will need to do some infra work on the monero-site side to support LGPL license terms. Is someone willing to make those changes? Also, we need to implement a license command or something along those lines correct?
jeffro256: To display the license body from the object code
jeffro256: rucknium: If the relevant people will join NWLB on Monday, then it could be moved there
jberman: my opinion on this is whatever moves this forward as fast as possible, I don't have a strong opinion on the license discussion itself
jberman: I think we should move on and if tevador wants to add to above tevador can
tevador: jeffro256: AFAIK we could just add the license file(s) to the release archive.
tevador: I have already explained why I'm not going to relicense.
jberman: ok, if tevador isn't going to relicense then I think let's just find a way to move forward with that
tobtoht: My personal opinion is that we should not burden every downstream ecosystem project with a restrictive license.
jberman: I think that's a fine opinion but we're stuck at an impasse here and I think it's best we move forward with it
tevador: The "restrictions" of LGPL are quite mild, even for closed-source projects that use the library.
UkoeHB: I am also against restrictive licenses both on principle and pragmatically (how much time wasted already on this? MIT gets no such drama). Is it possible an LGPL fork will just patent any changes they make, rendering the whole endeavor meaningless?
jeffro256: What exactly is the burden for downstream eco? That they must point to the Monero source ? Does that resolve section 6 since our repo would point to mx25519?
tevador: AFAIK there was no issue until tobtoht started to dispute the license.
jpk68: I don't want to be annoying and keep insisting on not having permissive licenses (at the expense of delaying things), but I feel like it's not a great idea to keep making non-ideal decisions, causing later technical debt, for the sake of finishing things faster
jeffro256: TBF looking over license terms is exactly what we need to avoid licensing issues ...
jpk68: At some point, one has to wonder how many concessions we're willing to make (Rust, LGPL, etc.) just to jam things through quicker
jberman: in this case I don't think there is much room for significant issues either way and both sides raise fine points
jberman: yes yes just to jam things through quicker than the 2 and a half years this has taken
rucknium: Given tevador 's statements, isn't a clean-room reimplementation of mx25519 the only way to avoid the LGPL in the Monero codebase? Anyone want to do that? If no, there seems to be only one option.
jpk68: jberman: Rewriting FCMP++ code in C/C++ would probably take longer than using the Rust library, no?
jberman: absolutely not
tevador: AFAICS the only change that would need to be made is to add the (L)GPL text to the release tarball. The rest is already solved.
jberman: sorry, absolutely yes*
sech1: Any code rewrite will require another code audit
jeffro256: tevador: Does does downstream have to do this if they use Monero as a library, instead of downloading releases?
jpk68: My point is simply that we shouldn't keep making compromises which will incur future technical debt under the excuse of saving time. In other words, I agree with tobtoht here
rucknium: IMHO, this issue should go on No Wallet Left Behind's agenda next week.
tevador: jeffro: It depends if they use the part that links to mx25519, then they have to also include the license file.
https://libera.monerologs.net/monero-research-lab/20260812
#nevent1q…r2up

2026-08-12 19:40:12 GMT

rucknium: 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (https://github.com/jeffro256/carrot/issues/10).
tevador: Maybe jeffro256 can comment. It's possible we can just accept the leak. But the fix is relatively cheap IMO.
jeffro256: Sorry for not answering, I have been looking into this and I think that, since the Carrot code has evolved since I originally unbound K^j_v, the original suggestion of re-including K^j_v won't add too much complexity. I will have an enginneed solution by EoW
https://libera.monerologs.net/monero-research-lab/20260812#c700120

2026-08-11 21:17:52 GMT

Monero Research Lab Meeting - Wed 12 August 2026, 17:00 UTC
Issue: https://github.com/monero-project/meta/issues/1440
https://npub1m0ner0mtjgs74aghus7qxrxl7mqv06d4v8rz9pmnux2dpr4cmhmsjgcfay.blossom.band/e612b6316bdef54fe70efedfcc29069ed28195bdd94b7187a271116ec795a0b0.png
Location: Libera.chat, #monero-research-lab (https://libera.chat/) | Matrix (https://matrix.to/#/#monero-research-lab:monero.social?via=matrix.org&via=monero.social)
Live log: https://libera.monerologs.net/monero-research-lab
Time: 17:00 UTC (https://www.timeanddate.com/worldclock/meeting.html?p1=1440)
Main discussion topics:
1) Greetings
2) Updates. What is everyone working on?
3) PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) - https://github.com/jeffro256/carrot/issues/10
4) 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
5) Relative locks with FCMP++ - https://github.com/monero-project/research-lab/issues/161
6) Shi, Zhang, Ge, Lan, Zhang, & Wang (2026) "Deanonymizing Monero Transactions in Tor Network." - https://arxiv.org/abs/2607.07062
7) FCMP beta stressnet - https://github.com/seraphis-migration/monero/releases/
8) Any other business
9) Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.
Logs will be posted here after the meeting.
Meeting chairperson: Rucknium
Previous meeting agenda/logs: https://github.com/monero-project/meta/issues/1431