MoneroResearchLab
Monero Research Lab (Unofficial)

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