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

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

rucknium and gingeropolous reproduced the Nyx eclipse in monerosim; countermeasures are under test. Attack needs ~1,000 IPs, each in its own /24. No mainnet Nyx signature in recent scans. Detectability: attacker must stuff reachable white lists, biasing honest peerlists. Moros poisons seed-node peerlists to eclipse newborns; authors did that on mainnet seed nodes around late Nov–mid Dec 2025, coinciding with scanner trouble. rucknium and rbrunner said that was not appropriate; authors could have run private seeds. Paper appendix says real new nodes would eventually escape. Tor safety board cited as contrast: https://research.torproject.org/safetyboard Countermeasures being coded: (1) white list 1,000 → 10,000; (2) try white list before gray list for new connections; (3) uniform white-list selection instead of most-recently-seen. #1 should not worsen this attack and was suggested twice by the same group, including https://moneroresearch.info/248 (NDSS 2025). Gray list still feeds reachability probes into the white list. Goal of a larger white list: if it exceeds reachable IPs, honest peers cannot be evicted. vtnerd warned recency bias helps after restart with dead ip:port pairs; rucknium said restarts use the anchor list first and is not committed to uniform selection. jpk68 asked for a written peer-handling spec; rucknium agreed and said Chesterton’s-fence deference to original CryptoNote P2P should end. White-list size 1,000 dates to the oldest codebase commit. ack-j posted repo-wide git-blame results: rucknium: 8. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260) rucknium: gingeropolous and I have been working on reproducing the attack in monerosim. It looks like the attack is reproducible. I have been testing countermeasures. vtnerd: doesn’t this require lots of /24 addresses, or am I missing something … ? rucknium: vtnerd: Yes it does. Well, about 1,000 IP addresses, each in its own /24 rucknium: I think it's possible to make this attack less costly, for little cost to monerod rbrunner: That's not nothing ... rucknium: I mean, make the attack more costly vtnerd: yes, understood. rbrunner: Nice that it's possible now to actually test it, no? rucknium: I am pretty sure that the attack would be detectable through a network scan of mainnet. I looked through a couple of recent network scans and I didn't see any evidence of the attack being attempted. I mean the Nyx attack of eclipsing an established unreachable node. The Moros attack is different, which I will get to later. rucknium: rbrunner: Yes. Our ability to test this was the result of several past decisions made in years past. rucknium: Mainly, gingeropolous adapting Shadow for #Monero, creating monerosim. And the hardware purchases of 1TB RAM. Thank you, CCS donors! jpk68: rucknium: Do you think it would be eventually worthwhile to have a written document outlining the specific required logic for handling peers and such, in order to protect against faulty implementations and ensure reference implementation behaviour remains correct? rucknium: jpk68: Definitely. rucknium: A lot of the logic was inherited from Monero's ancient Cryptonote ancestors. The ancestors speak no longer (or at least they don't identify themselves). ack-j: It would be interesting to scan the git history of monerod to see which lines of code are the oldest without being updated rucknium: We don't know the reason things are written they way they are. Maybe it was to maximize connectivity with honest nodes but they did not fully explore what an adversary could do. jpk68: I mean, even with some remaining similarities, this research could probably be useful for projects like Zano and MobileCoin (if it still exists...) as well rucknium: ack-j: One of the big ones is white list size 1,000, which is with the oldest commit of the original codebase. rucknium: The reason that I think the attack is detectable on mainnet is that the attacker needs to stuff reachable node white lists with their own IP addresses, pushing out honest IP addresses. In that case, the peerlists the honest nodes share would be biased. I performed some chi-squared tests and found no obvious bias. rucknium: I think it's time to stop using the "Chesterton's Fence" reasoning to give the benefit of the doubt to the original cryptonote network code. rucknium: rbrunner and I puzzled over some of that code when we added the /24 deduplication rule. jpk68: rucknium: As in, stop questioning it, or begin questioning it? I assume you mean the latter rucknium: Begin questioning it. rucknium: The second attack in the paper, Moros, requires the attacker to stuff the peerlists of seed nodes to eclipse brand new nodes. rbrunner: Well, not knowing why a fence is there is compatible with seeing that today it's not good anymore rucknium: The research team actually did that to mainnet seed nodes. ack-j: ack-j: Results from git blame ack-j: Over every line in the monero repo rucknium: They said they did it in the paper. And I think I see some evidence of their poisoning in late November to mid December 2025, in the network scan data. rbrunner: Hmm. Is that still friendly, to be expected from people who write papers? rucknium: Which was coincidentally around the time that I though my network scanner code was failing to do its job. It would make sense that my scanner was finding it hard to scan if the seed nodes were poisoned. rucknium: rbrunner: IMHO, they should not have done that rucknium: They could have set up their own "seed nodes", even on mainnet, and modified their nodes' code to point to those seed nodes. You could have the same effect IMHO. I mean, test the theory without messing with mainnet real seed nodes. rucknium: They say in the appendix that actual new Monero nodes would have eventually gotten out of the eclipse. rbrunner: Did not fully read the paper. Is that "Moros" attack alone able to achieve something dangerous? rucknium: Tor has a research safety board for this kind of thing by the way: https://research.torproject.org/safetyboard rucknium: rbrunner: It could eclipse newborn nodes from the start. Not as widespread of a problem as eclipsing all the established unreachable nodes. rbrunner: I see rucknium: The countermeasures I am testing are 1) Expand the whitelist size from 1,000 to 10,000. 2) Try to add a new conenction from the white list first instead of the gray list. 3) Select new connections uniformly from the white list instead of biasing toward the most recently seen ones. rucknium: Those countermeasures are the intersection of what I think may be effective and what I can actually code myself in C++ rucknium: :D rbrunner: Sounds interesting, where it's probably not immediately clear for all 3 whether it's a good idea or makes things actually worse rucknium: I am pretty sure #1 cannot make things worse, at least with this specific attack. rbrunner: Is the gray list still good for something with 2) implemented? ofrnxmr: can the white list even get that big without constantly evictinf and switching peers? rucknium: Actually this research group has suggested to Monero twice to increase the white list size limit. rucknium: rbrunner: Yes because there is a housekeeping method that tests gray list peers for reachability, then puts them in the white list if they are reachable. But it doesn't add those as an actual connection unless it is later selected from the white list as a new connection. rucknium: The purpose of increasing the white list size is to prevent manipulative adversaries from pushing out honest peers from that list. If the list is larger than the total reachable IP addresses, the honest peers cannot be pushed out. vtnerd: one problem I see is that if you restart monerod, then the recently connected helps with dead ip/port pairs rucknium: This is the paper last year where they suggested increasing the white list size: https://moneroresearch.info/248 Shi, R., Peng, Z., Lan, L., Ge, Y., Liu, P., & Wang, Q., et al. 2025, February 24–28, Eclipse Attacks on Monero’s Peer-to-Peer Network. U paper presented at Network and Distributed System Security (NDSS) Symposium 2025. vtnerd: *selecting/bias from the recently connected rucknium: vtnerd: IIRC, on a restart you select from the anchorlist first. rucknium: I am not committed to uniform selection from the white list. Just testing things now. https://libera.monerologs.net/monero-research-lab/20260923#c710195

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

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

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

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

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

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

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

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

jberman: next item on my plate here is rebasing on top of master (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