05:45:10 Will try. Sadly my old brain forgot many of the details of that list management already however ... 11:24:37 dunno if i'll make the meeting today. Some updates - i started implementing features into monerosim that require modifications to monerod. 1st was a way to test hardforks, this was done weeks ago. 2nd is using actual PoW in the simulation so we can test all the fun selfish mining countermeasures. i think that one is mostly don [... too long, see https://mrelay.p2pool.observer/e/gfXVm6sLWThLcG9P ] 14:28:32 https://mrelay.p2pool.observer/m/monero.social/aARReNmOfcqmogJOgeuGHTyg.png (image.png) 14:29:06 For the meeting later today, here is the anonymized table of quotes that we received for the FCMP++ circuits audit 15:00:34 MRL meeting in this room in two hours. 17:01:02 Meeting time! https://github.com/monero-project/meta/issues/1458 17:01:07 1. Greetings 17:01:09 Hello 17:01:14 Hello 17:01:16 Hi 17:01:16 Hello 17:01:21 Hi 17:01:36 waves 17:01:56 Hi 17:02:03 Howdy 17:02:23 Hi 17:03:12 2. Updates. What is everyone working on? 17:04:06 me: Selfish mining defenses. Reading the new Monero research papers and trying to reproduce their results. 17:05:09 me: still on ssl fixing the —proxy issue. realized our existing p2p connection routines block an ASIO::run call via synchronous code such that you need at least 2 ASIO threads for the p2p server to work. so figuring out whether I should just keep the existing issue or fix it all 17:05:31 or else I misunderstood the logic, but I think Ive got it 17:05:32 me: A version compatibility testing framework. Supports cross-version compiling, functional testing, and Python<->C++ FFI. Trying to make the UX for writing and running tests very easy so people actually use it. Will publish first commit by EoW 17:05:34 also serialization stuff 17:06:16 me: finished hot-cold PR review (that was merged! 🎉 huge effort by @jeffro256:monero.social), working on rebasing the FCMP++/Carrot development repo on top of latest master 17:06:25 in prep for beta v3 17:08:01 Huge review effort too. Thanks to j-berman, selsta, thomasbuilds, et al 17:09:11 Me: posted before start, but turns out there's a buffer cap in shadow that was limiting the rpc peer list pull . Testing now 17:10:22

I reached out to the author who may join us during next weeks meeting > <@ack-j:matrix.org> https://ieeexplore.ieee.org/abstract/document/11676613 17:10:37 Thanks, @ack-j:matrix.org 17:10:57 3. Tehrani & Tovanich (2026) "MoneroVis: Visual Analytics for Exploration and Traceability in a Privacy-Preserving Blockchain" (https://dnvie.com/docs/MoneroVis.pdf) 17:11:09 With us today we have Daniel Nikbakht Tehrani ( @dnvie:matrix.org ), the lead author of the paper. Welcome! 17:11:27 👋 17:11:36 @dnvie:matrix.org: Do you want to briefly summarize the paper and tool? 17:13:30 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 algorithm [... too long, see https://mrelay.p2pool.observer/e/mbvTpasLQVhyd2Jl ] 17:14:07 A live instance is running at https://monerovis.com . Open source code is at https://github.com/dnvie/MoneroVis 17:14:51 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 17:15:30 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 17:15:53 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. 17:16:56 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 17:17:08 Can the user control the ring size 17:17:40 No, not since many upgrades go 17:17:43 *ago 17:18:01 Ring size for all v16 txs is fixed at 16 17:18:16

@dnvie:matrix.org: were you able to use monerovis to identify any recent true spends? 17:18:17 I mean on Monero Vis 17:18:39 @dnvie:matrix.org: It seemed pretty fast, even over a Tor connection. I admire that because my data webapps are usually slow 😅 17:18:54 @ack-j:matrix.org: We only used the WannaCry funds as a case study so far 17:19:20 @articmine: What exactly do you mean with controlling ring size on MoneroVis? 17:19:47 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 17:20:23 Simulation of different ring size for impact on the accuracy of heruistics 17:20:35 Cool tool. Did you implement P2Pool miner sweep detection? https://p2pool.observer/transaction-lookup 17:20:46 @jeffro256:monero.social Do you still have a link to the transaction with the highest recorded ring size? 17:20:50 Although it will require real-time tracking of P2Pool chains 17:20:54 I lost the TXID, apologies :) 17:20:58 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 17:21:20 I see use outside of Monero for MoneroVis 17:21:27 hi, me: chipping away at wallet2 hardening PRs as LLMs flag stuff 17:21:44 sech1: No 17:21:51 And that analysis would end up with "the trail runs cold". But at least it uses the output merging heuristic in the beginning. 17:22:00 @rucknium: Interesting, I will take a look at this 17:22:31 @articmine: No, you can only use “live” blockchain data, no simulations 17:22:41 @jpk68:matrix.org: Uh I should yeah. Gimme a sec 17:23:17 @jeffro256:monero.social: So you are about to break MoneroVis :D 17:24:05 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. 17:24:52 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) 17:25:14 I assume the paper is in its final state, so it cannot be edited at this point. 17:25:23 @rucknium: Will do 17:25:28 @rucknium: correct 17:25:45 @jeffro256: Browser tab with that open is using 790 MiB of RAM ;) 17:26:10 You say 17:26:10 > 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. 17:26:50 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 17:27:33 You don't need ground truth to estimate probabilities. 17:29:57

@dnvie:matrix.org: 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 :/ 17:29:57

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 17:30:15 @rucknium: This can be a highly controversial subject in Bitcoin. 17:30:15 In fact the reliability of these money flow heruistics is currently the subject of an appeal before the US Court of Appeals DC circuit 17:32:04 This is I consider this very valuable research 17:32:25 @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 defi [... too long, see https://mrelay.p2pool.observer/e/vuGYpqsLdnNrN0Rh ] 17:32:40 @ack-j:matrix.org: Thanks for sharing! 17:33:27 @dnvie:matrix.org: I may give some followup questions and comments after the meeting if you don't mind. 17:33:43 @rucknium: Sure 17:33:52 More questions and comments for @dnvie:matrix.org for now? 17:34:20 I will wait for after the meeting 17:35:09 thanks for calling them "poisoned outputs" not some other weird name 17:36:30 Monero has multiple names for everything :D. Did you know that the Monero code refers to decoys as "fake-outs"? 17:36:36 @dnvie:matrix.org: Thanks for your work and for attending the meeting, @dnvie:matrix.org ! 17:36:49 @rucknium: Thanks for having me! 17:36:56 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 [... too long, see https://mrelay.p2pool.observer/e/7quppqsLTHFpVXo3 ] 17:37:58 The prior topic of rings needing replacing moves us nicely into this topic, of another security audit of Monero's FCMP++ circuit 17:38:26 @sgp_:monero.social: That's next agenda item. I want to get any updates on the full picture before that 17:38:39 ah sorry :) I'll wait 17:38:44 I misread 17:40:38 With the hot-cold implementation ready for testing, now working on rebasing the FCMP++ branch on top of latest master. Then we'll take care of final beta v3 tasks, and UkoeHB can also continue with getting multisig rebased on top of the latest as well (once we're back on master) 17:42:17 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:matrix.org ) 17:43:09 No plans to include RandomX v2 into beta v3? 17:43:26 Is that ready? 17:43:38 There is a PR to master branch 17:44:07 Which hasn't received approvals yet because it does some controversial changes on top of RandomX v2 17:44:39 github.com/monero-project/monero/pull/10038 17:45:25 do you think it's something that warrants needing rigorous beta stress testing? doesn't seem like something to necessarily hold back beta on 17:46:10 It should "just work", but it will need testing eventually somewhere. No necessarily in beta v3 17:46:40 beta itself isn't really blocking anything upstream, so it's not a big deal to try to get this in 17:47:30 I'll leave it to @jeffro256:monero.social thoughts on path forward there. I can look at that PR soonish too 17:47:44 Sorry I haven't responded to that PR in a while. I will do that this week 17:48:24 I need to find my flow chart files to make modifications 17:48:29 Re: upstream FCMP++ integration PR's. Here are the latest 3 PR's lined up all ready for review: 17:48:34 https://github.com/monero-project/monero/pull/10361 17:48:38 https://github.com/monero-project/monero/pull/10362 17:48:45 https://github.com/monero-project/monero/pull/10724 17:48:54 10361 has gotten reviewed I think should be good to go 17:49:02 10362 is fairly small 17:49:14 10724 is significant, it's the FCMP++ curve tree builder 17:50:04 That rounds out Phase 2 for FCMP++ integration 17:51:00 I added a licensing library here: https://github.com/monero-project/monero/pull/11288. Any thoughts tevador or tobtoht about it in general?\ 17:51:24 I think tobtoht is gone this month 17:51:36 Biggest status update on FCMP++/Carrot front is the hot-cold PR merge though. That PR was massive and the changes were significant to get that working, huge props to @jeffro256:monero.social there. Multisig will probably be the next major milestone to look for 17:53:50 More on this agenda item? 17:54:42 nothing from me, should hopefully have all code ready to go for beta v3 by next week and we can schedule it at that point 17:55:19 5. Second FCMP++ circuit review: CCS approval. 17:55:54 MAGIC Grants (with a lot of help from Berman) sent out an RFQ for a second independent audit of Monero FCMP++’s generalized-bulletproofs-circuit-abstraction, generalized-bulletproofs-ec-gadgets, and full-chain-membership-proofs, plus an initial audit of fcmp-plus-plus. We requested that the audit scope exclude both proving and multisig. The seven quotes we received are: 17:56:09 https://mrelay.p2pool.observer/m/monero.social/XCgmAfDllSezLXxwOoeDvmCC.png (image.png) 17:56:40 I believe that vendors 1, 2, 3, and 7 are the best qualified for this scope. My recommendation is to pick vendor 2 and for them to review proving but not multisig. The circuit review would be nice to have, whereas the multisig review is more likely to cause distraction. Plus, since it isn’t formally defined, reviewing it now [... too long, see https://mrelay.p2pool.observer/e/wMzxpqsLaGxSZTdv ] 17:57:24 Seconded 17:57:47 I don't know how to evaluate all the options if I don't know who is behind them, what are their credentials and past work. But from the dates point of view, does it set back the FCMP++ hardfork? 17:58:09 I don't really like the anonymized review quotes. I guess this is just the way it's going to be done. 17:58:52 My understanding (berman can say more) is that it doesn't delay anything 18:00:24 no none of this is likely to set back the fork, I think we're bottlenecked by getting all the code actually completed and merged at this point, not Research audit 18:01:27 Anon encourages people to apply instead of "punishing" them. If a vendor wants to say "I am this one" then that's fine with me. We're working on an RFQ platform and as part of that, we can have a feature for people to say they are ok being named publicly like this, but I don't want to assume and risk a relationship 18:02:04 Any comments about the high quote of 3? 18:02:34 They are highly qualified but cost way more 18:03:05 So in general then, not only for this review? 18:03:19 Who is actually aware of the identity of the bidders 18:03:39 Berman, Jeffro, and kayaba 18:04:14 I personally liked 1 and 3 as well, but candidate 2 also seems highly qualified based on past work they've done and so it makes sense to go with them considering the quote 18:05:30 and I agree on including prover but not multisig 18:06:44 @sgp_: I also think this is valid reasoning for not naming the vendors publicly. obviously this makes it a bit challenging for everyone else to evaluate though, heard on that front 18:08:09 If a long-time community member wants the table, you can DM me, just keep it private please out of respect for the bidders 18:10:01 More questions and comments on this before approval is attempted? 18:10:37 I DM'd to you @rucknium:monero.social and @articmine:monero.social 18:11:02 Thanks. 18:14:35 Thanks 18:15:05 My honest opinion is I am not 100% comfortable with #2 18:15:59 I don't intend to strongly influence the decision, but I need to give an honest opinion here. 18:16:04 @rucknium:monero.social: is there another one you are more comfortable with? 18:17:13 #2 has some of the best overlapping experience with frameworks specifically, not just the proofs. 1, 2, 3, and 7 have experience with frameworks 18:19:26 @sgp_: Is this the opinion of Berman, Jeffro and kayaba? 18:19:43 If so I am free 18:20:22 Fine with not knowing the identity of the bidders 18:22:22 I preferred 2, excluding multisig 18:22:50 I didn't firmly evaluate that they necessarily had the best experience. I felt that they all had the requisite experience. Not to argue against that claim, I just can't say 18:24:01 @sgp_: #1 looks good to me. 18:27:08 I preferred #7 after #2, and therefore over #1, FWIW 18:27:48 How would we weight that we don't have start date yet from 1? 18:28:35 I don't think start date is highly relevant, I think we can very comfortably say it won't delay anything either way 18:28:46 Ok 18:29:27 I forgot to add theirs to the chart. It is Sept 30 - Oct 30th. So in line with the others, so time isn't a meaningful factor 18:30:28 So maybe not a bad idea to let this ripen for a week more? 18:31:03 If that's ok with the bidders ... 18:31:22 My 2c is that in terms of a quality review, 1,2,3, and 7 are all good choices. If money was no object, maybe I’d slightly lean 3. But with money as the tie-breaker consideration, I kinda have to recommend 2 18:32:10 More scope covered by a competent reviewer for less money? Yes please 18:33:00 I would delay a week but I don't think we will learn anything new that influences the decision 18:35:05 I think things seem at least narrowed down to 1, 2, 3, or 7 18:37:27 Maybe we can get approval for any of those and you can make your case for 1 outside the meeting Ruck? Ideally within the next 24 hours or so? The four of us initially settled on 2 before the meeting but if you have stuff to share that would be great. I don’t want to delay things just to delay them though 18:37:40 I hesitate to say this, but to those who know the firms' names: I assume you know why I am not 100% comfortable with #2. Anyway, I said that I didn't want to influence this much since it's not in my area. Other than me, it seems people here are ok with #2 18:39:24 #1 has also been discussed as a good option for a while, prior to now. 18:39:38 For those of us who are not well-informed, is it because #2 is a less reputable vendor? 18:39:43 Apologies if this is a dumb question :) 18:40:10 i dont understand the anonymous quotes when 1 person (or more) knows exactly who they are and are offering feedback to their qualifications :D 18:40:53 @sgp_: I am OK with tentative approval for #2. Then I will make my case in private. 18:42:00 I suppose the alternative to this process is to not have a public discussion of which vendors, and just let @jberman:monero.social , @jeffro256:monero.social , and @kayabanerve:matrix.org decide alone. So this process is a little more open than it could be. 18:43:27 Yeah the "normal" process for this would be a committee discussion, but it's more open out of respect for the CCS donors to know that their donations are being used wisely and for its intended purpose 18:44:44 We can attempt consensus on #2. I don't know how to word the "tentative" part to put it into a proposal statement. 18:45:21 "approval on 2, with an opportunity to reconsider based on what ruck says" ? :p 18:45:59 Well, I myself would continue to trust the trio of jberman, jeffro and kayaba to vote for 2, but of course your doubts, Rucknium, gives a question mark :) 18:46:41 A two stage process can work. I am supporting 2 after careful review of the comments and anonymized bids 18:47:11 Proposal is: "Approve hiring firm #2 for second FCMP++ circuit review. However @jeffro256:monero.social , @jberman:monero.social , and @kayabanerve:matrix.org can choose by majority vote to bring the issue back to MRL next meeting within 24 hours." 18:47:39 In favor 18:47:47 Can we get consensus on this proposal? 18:48:17 Support and any objections? 18:49:27 I approve #2 soooo 18:50:12 I also approve 2 18:52:23 I see loose consensus here in favor of "Approve hiring firm #2 for second FCMP++ circuit review. However @jeffro256:monero.social , @jberman:monero.social , and @kayabanerve:matrix.org can choose by majority vote to bring the issue back to MRL next meeting within 24 hours." 18:53:08 6. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161). 18:53:40 Ty Rucknium, I am eager to hear your opinion. We definitely want the best reviewer 18:54:34 I don't know if anything has changed with relative locks. IIRC, tevador and @jberman:monero.social were discussing tests. 18:56:43 no update from me. I think it's fine to keep it as an agenda item in case people want to discuss. Also can be labeled "Enabling payment channels with Relative locks with FCMP++" 18:57:10 7. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). Version 3 launch checklist (https://github.com/seraphis-migration/monero/pull/415). 18:58:38 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 18:59:20 > <@jberman> Final beta v3 tasks after would be: rolling back the chain automatically for anyone using beta already, setting the higher min penalty zone, and any other beta specific PR's necessary. That's all very minor work. The rebase on master is taking a bit since there have been a lot of changes (plus noted what looks [... too long, see https://mrelay.p2pool.observer/e/no3XqKsLS29aeHJj ] 18:59:20 mentioned the tasks over here. I'll hold on discussing beta until this agenda item in the future 19:00:12 for IRC folk I was referring to this: https://libera.monerologs.net/monero-research-lab/20260916#c708186-c708187 19:01:14 Thanks :) 19:02:48 sgp_ tbh "more open out of respect for the CCS donors " would be here are the candidates and their quotes , the committee have chosen this because xyz, any objections? which is fine, its just odd when you have people like sech want to be involved and theyre looking at a $ number and nothing else 19:05:17 More on stressnet? 19:06:03 8. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260) 19:06:07 That's it from me 19:06:19 Finally here. And we have held on to rbrunner ! 19:06:41 Indeed. 19:06:49 Probably best to have an initial discussion, with plans to continue in more depth next week. 19:06:59 Is @boog900:monero.social here? 19:07:11 Hi 19:07:14 yes 19:07:54 I am skeptical of the paper because I cannot get their reproduction code to run. However, I find their theorized attack to be plausible, given monerod's design decisions. 19:09:30 Basics: An eclipse attack happens when an adversary (who wants to do something bad) completely isolates one or more honest nodes from the rest of the network. The honest node thinks it's connecting to other honest nodes, but actually all of its peer connections are to a node (or pseudo-node) controlled by the adversary. 19:10:35 So they say they can eclipse unreachable nodes (nodes that are behind firewalls so they do not accept inbound connections) by poisoning the peerlists of honest nodes. The honest nodes inadvertently give the targeted unreachable nodes the peerlists of the adversary. 19:11:52 I think it's caused by two design decisions that may be design flaws: 19:11:52 1. Allowing inbound connections to control the pace of adding new IP addresses to honest nodes' peerlists, specifically their whitelists. 19:12:06 2. Limiting the white list to 1,000 peers. 19:12:27 If you fix one or both of those, you would fix the attack probably. If the attack actually works. 19:12:37 so far my replication attempts are confirming the findings, but I'm running into issues with shadow. Currently running what I hope is the final run. 19:14:06