00:31:30 Delicious 9/&0 00:31:37 9/10* 00:38:56 🏇 00:39:11 🏇 for real 01:58:15 > In 2017, the protocol safeguards were strengthened to thwart the techniques used by Möser et al. (2018). 01:58:15 Doesn't that read like the protocol received some enhancements based on a paper that was... published a year later, or what does that 2018 in parentheses stand for? 01:58:17 > Note that the OSPEAD research has not yet been formally peer-reviewed. 01:58:19 Are you planning on getting it peer-reviewed at least once, or will you leave it at the MRL committee who got access to it? 01:58:21 > *Developments to come* 01:58:23 > 01:58:25 > The OSPEAD-derived decoy selection distribution could be deployed to mitigate the risk of the MAP Decoder attack. However, a Monero network upgrade (hard fork) would be required for safest deployment. A network upgrade, though necessary for major improvement to Monero, is disruptive to the Monero ecosystem. The costs may outweigh the benefits. 01:58:27 > 01:58:29 > Currently, the next expected hard fork is set to deploy Full-Chain Membership Proofs, which eliminate the weaknesses of the ring signature privacy model. 01:58:31 Thoughts on an opt-in softfork to mitigate? While not as disruptive, would be keep focus on FCMP++'s network upgrade and per your previous response, it might still be benefitial to deploy OSPEAD improvements in some edge node connecting processes, isn't that right? 01:58:33 Otherwise, draft looks good. Would you be okay with me sharing it in Revuo if it hasn't gone live by Sunday for next issue? 02:02:39 Rucknium: Cam I fit my above comments from Matrix into tomorrow's discussion on the contest, please? 02:10:45 Thank you for not saying equivalent to ringsize 4. I think the current wording there is much clearer and more accurate 02:17:34 I recommend adding a few sentences along the following: 02:17:35 Let's continue the analogy of the horse race bettor. Did they pick the winning horse (truly spent input enote)? Unlike a normal race, we don't know the specific outcome (if the guess was correct). This limits the impact of the attack in practice, especially since the best guess is incorrect the majority of the time, on average. 02:18:17 I recommend adding a few sentences along the following: 02:18:17 Let's continue the analogy of the horse race bettor. Did they pick the winning horse (truly spent input enote)? Unlike a normal race, we usually don't learn the outcome (if the guess was correct). This limits the impact of the attack in practice, especially since the best guess is incorrect the majority of the time, on average. 02:20:28 Put another way, if you guess the truly spent enote in 4 Monero rings, you will have guessed 1 of those correctly (on average), but you don't know which of those guesses is correct. 02:22:16 Is that useful information? That depends™️ 04:24:56 "However, a Monero network upgrade (hard fork) would be required for safest deployment." are you suggesting there is a consensus way to enforce decoy selection algorithms? 04:42:24 or is it just that a hard fork would be a means to get everyone to upgrade 04:56:04 Also curious about this. Given 16 decoys, how can you check for proper selection algorithm use? 05:24:40 like a consensus KS test? 11:47:22 from looking at previously created blocks, you could not be sure which selection algorithm was used. And thats not what @rucknium:monero.social meant with "hard fork" - i hope. This would be over-reacting anyway. Meeting today ? 11:48:25 YES 11:48:27 sorry for caps 12:27:29 from looking at previously created blocks, you could not be sure which selection algorithm was used. And thats not what @rucknium:monero.social meant with "hard fork". Rather the next hard fork (fcmp++) would get everyone to upgrade, to avoid yet another statistical attack when different selection algorithms would be used simultaniously 13:37:22 https://duke.hush.is/memos/6/ 13:53:21 Rule 3 is a bit of a pain in the ass 13:54:28 Actually, just maintaining two separate wallets (one incoming and one outgoing) is a pain in the ass 14:17:22 naw, i was pulling from a part of the document that was talking about using a better decoy selection algo, not the switch to FCMP. But yes, the fork to FCMP will take care of the issue. I'm just curious if we should (or can, if we can enforce a better decoy selection algo), gear up for the possibility of another 2+ years with ring sigs by implementing the ospead technique 14:20:46 rottenwheel: 14:21:07 > Doesn't that read like the protocol received some enhancements based on a paper that was... published a year later, or what does that 2018 in parentheses stand for? 14:21:09 The Moser paper mostly used zero-decoy transactions (and low-decoy transactions that were subject to chain reaction attacks because of the many zero-decoy txs) to de-anonymize txs. MRL and Monero devs knew that allowing zero-decoy rings were a bad idea, so they started requiring minimum ring sizes. And the Moser paper even says that RingCT and larger ring sizes thwarted their tec hniques in 2017. See their Figure 5 https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=15 14:21:13 Anyway, a draft of the Moser paper was released in 2017. 14:21:15 Rucknium: 14:21:19 Ah, it came through. :P 14:21:38 > Are you planning on getting it peer-reviewed at least once, or will you leave it at the MRL committee who got access to it? 14:21:39 Maybe. Probably Proceedings on Privacy Enhancing Technologies (PoPETs) is the best venue because 1) They would have good reviewers familiar with the subject matter and 2) a lot of the conversation about the ring signature privacy model has happened in its pages. For example, Moser et al. (2018) and Ronge et al. (2021), both cited in the draft blog post, appeared in PoPETS. Last ti me I checked, Moser et al. (2018) was the 4th most-cited article in the whole history of the PoPETS journal. (But most of the citations have been in passing, like "Yes, there are some privacy coins, but it doesn't always work [CITE]". A 2025 Bank for International Settlements paper did this, even though the paper is old and its specific conclusions no longer apply. 14:21:43 But PoPETs editors might not be interested since cryptocurrency privacy is moving away from the ring signature model. On the other hand, IMHO, the ideas of OSPEAD are potentially applicable to more domains where decoys still make sense, e.g. when a user is querying a central service. Asking for directions from one location to another is giving privacy-sensitive information to a se rver. Of course, users do not request directions from locations on the planet with uniform distribution. That depends on population density, etc. So you could construct probability distributions based on the two dimensions of latitude and longitude. With OSPEAD, the system could work even if not all users are using the same decoy selection protocol. 14:22:18 > Thoughts on an opt-in softfork to mitigate? 14:22:19 The decoy selection algorithm is a wallet-side procedure, not node-side. A soft fork on the node side that doesn't require a wallet-side upgrade probably would not have a bigger effect than just releasing new wallet-side code. The problem with partial userbase upgrade is anonymity puddles. for example, according to my calculations in https://github.com/Rucknium/misc-research/blob/ main/Monero-Fungibility-Defect-Classifier/pdf/classify-real-spend-with-fungibility-defects.pdf , if only 5% of users upgraded to the OSPEAD decoy selection algorithm, the attack success probability against them would be 32% (assuming perfect classification by DSA), actually higher than the 23.5% attack success against the current DSA. That would be a net loss in privacy. 14:22:27 > Would you be okay with me sharing it in Revuo if it hasn't gone live by Sunday for next issue? 14:22:27 Let's leave that question unanswered until after the meeting today. 14:22:45 kayabanerve: Yes 14:23:19 sgp_: Those additions sound great to me. Thanks! 14:23:59 gingeropolous: 8trmns : Mostly, just a means to get everyone to upgrade so that the partial upgrade doesn't create anonymity puddles. However, you could have a relay rule that requires a specific decoy selection algorithm. AFAIK, koe came up with the idea first: https://github.com/monero-project/research-lab/issues/84 . I try to explain it here: https://libera.monerologs.net/moner o/20250224#c501465-c501466 14:24:03 AFAIK, you can use it for non-binned rings, too. More info here: https://github.com/monero-project/research-lab/issues/873/5/25 14:24:12 Hopefully getting clarity on whether OSPEAD proposed improvement will go live hand-in-hand with FCMP++ and if so, a draft roadmap would be great to have. :D 14:24:39 Thanks for the insights. Looking forward to today's meeting. 14:26:19 8trmns: IMHO, a Kolmogorov-Smirnov test would not be a good idea here. You would have low statistical power at current ring size and you would reject a small number of correctly-constructed transactions. 14:29:41 I did lots of professional behavioral modeling - poker players, musicians on stage and stock markets - and again and again we found the assumption "past behavior is the best predictor of future behaviour" to be wrong in surprising ways. Often the "perfect" distribution function changes after holding true for some time, just when there is skin in the game. TL;DR when you pick a cer 14:29:41 tain decoy, your chances of hitting the right one will often be much worse than 1:4.2 in practice 14:32:10 An adversary doesn't have to forecast the future. Monero developers do. That puts Monero developers at a disadvantage. 14:32:32 An adversary can re-estimate the model on the data in any given week, which is exactly what I do. 14:33:35 That wont help IMO but as you hint - there is a political dimension 14:33:53 The "S" in OSPEAD stands for "static", which means it doesn't change in the future. That's a weakness of static decoy selection algorithms, but coming up with a dynamic one that is resistant to even spam attacks is difficult 14:34:59 will need to "salt" with randomess in any case 14:35:22 will need to "salt" with randomness in any case 14:36:49 Visualizations of week-by-week real spend distribution estimates are at https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/real-spend-visualization.html 14:37:18 I appreciate your input:) 15:01:43 MRL meeting in this room in two hours. 17:00:45 Meeting time! https://github.com/monero-project/meta/issues/1167 17:00:50 1) Greetings 17:01:13 Hello 17:01:22 hi 17:01:25 hi 17:01:26

Hi 17:01:42 hello 17:01:50 *waves* 17:02:10 hi 17:02:16 Hi 17:02:54 Hi 17:03:06 Hello 17:04:26 2) Updates. What is everyone working on? 17:05:18 👋 17:05:30 me: created an FCMP++ tx with the CLI on a local testnet, continuing with cleaner code organization. Also caught a virus so was out of commission past couple days. Back now 17:05:36 working on figuring out whats going on with haveno with the release branch updates. getting haveno running is a bit of a beast in itself 17:05:38 me: Wrote a draft getmonero.org blog post on OSPEAD: https://gist.github.com/Rucknium/e18c514f0ba7a6dc6c7f35f9c242a34a 17:06:47 vtnerd doing some haveno work? 17:07:17 no, just trying to figure out why their tests fail with recent monero changes 17:08:41 jeffro256: ping in case you need it 17:08:48 3) Prize contest to optimize some FCMP cryptography code. https://github.com/j-berman/fcmp-plus-plus-optimization-competition 17:09:11 Howdy 17:10:47 "How long do you believe it would be before the contest starts?" - Let's say we finalize rules today/tomorrow, and we have the general fund cover the contest prizes, we could feasibly open the contest for submissions by early April. That pushes your timeline up by just 2 weeks, so ya I'd say that estimate is fairly accurate 17:11:02 "Also, @jberman, you shouldn't bench scalar_mul_divisor alone" - ok, valid points. I'll update that. 17:11:45 I raised questions above on timeline until a winner is selected, from organization to fundraising to execution to selection, and aired the idea of auditing the current libs for an initial release. 17:12:32 Of note, I included a new clause in the competition rules that we can determine winners at our discretion (that would potentially disqualify such a submission / allow us flexibility in judging), but agree that is a reasonable point to fix for ec-divisors 17:13:10 IMHO, the CCS for fundraising needs to specify what happens with the funds if no submissions exceed to 20% speedup threshold. Probably makes sense to put it toward one of the FCMP CCS efforts (dev/research). 17:14:15 "If these libs are a bottleneck, I'd propose auditing the current libraries, being ready to ship them as-is" - I'm not comfortable with shipping tree building in wallets as is, it would slow down wallet sync a significant amount. I would re-work it to download missing tree elems if we don't get a significant speed up in time for v1 release 17:15:27 The dev CCS is mine outright, with no distinct distributions/rollover, so I support that one being the fallback /s 17:15:59 Yeah the timeline that Kayaba pointed out is probably pretty accurate, which makes it important to get the competition rolling soon if we're going to do it. There's a ton of stuff that we also need to do in the next 6 months, but the underlying FCMP lib is a dependency of most future dev work, and not everything has the same criticality to be audited upon release. For example: mul tisig code and hardware device application code. 17:17:22 My thinking behind proposing going with the general fund for this is three-fold: 1) speeds up the time to get the contest rolling, 2) relatively simple to handle the case where no submission exceeds the 20% threshold (funds stay in the fund), and 3) the fund is sitting on a lot of Monero for general development of which I think this qualifies 17:17:48 If we do go down this path, I would wait a little bit until we finish integration, so that details of the API can be tweaked before auditing. AFAIK, the Monero integration will be the first live project using this crate(s) as a dependency, and a lot of QoL issues can be ironed out during this time 17:18:07 And to think I just started to poke at auditing the SAL and associated multisig code 😱 Get out of my head jeffro 17:18:50 Multisig specifically has an explicit line item under the research CCS FWIW 17:19:48 jeffro256: Not to be rude, ec-divisors is like, two functions 17:20:34 Said API is already well-suited to the stack, being designed for it, and integrated 17:21:06

What are the plans to market the competition (if any)? Does anyone know of places where talented and qualified developers would communicate? We could maybe take an ad out on codeforce.com 17:21:39 Then for helioselene, it doesn't have its own API. It uses the ff/group APIs 17:22:01 The libs discussed re: the contest really aren't an API concern 17:22:15 Extensive meme operation that only ccryptographer understand would be a first step imo /s 17:22:26 Lol yeah that part is fine, I meant more of the higher level stuff, mainly in the monero-fcmp-plus-plus crate 17:23:02 xmrCicada 17:23:22 podcasts, ACM, cryptographer journals, cryptographer reddit / other social media accounts 17:23:42 Also, jberman, while I recommended benching new and scalar_mul_divisor together, new should have a weight applied to it (I think 12/13) as we do 12 news but 13 smds. 17:23:44 just annouce it on getmonero.org blog? 17:24:15 not enough exposure 17:24:24

I agree but doing that is simply not enough to attract talent outside the Monero community 17:24:35 So a solution with a 10s new and 1s divisor is explicitly better than a solution with a 0s new and 11s divisor 17:25:39 I say this b/c sometimes seemingly-harmless API changes can open up crypto vulnerabilities, like the EdDSA double-pubkey oracle attack 17:26:22 how about CTF platforms? 17:27:07 That's why I baked all the vulnerabilities into the *existing* API jeffro /s 17:28:27 where does new get called without a corresponding scalar_mul_divisor? 17:29:22 Other way around jberman 17:29:37 true, same q 17:30:06 We do two smds off one new for a single scalar, the key image generator blind 17:30:43 It's against U for the blinded key image but against V for the commitment to itself IIRC 17:31:15 That's also why the two functions exist: to save that single preprocess. 17:33:33 ok, and also where do you get the figures 12/13 from? assuming specific number of layers + 1 input to the proof? 17:34:55 on marketing, does someone want to help take that on? :) 17:36:23 Yeah. More inputs doesn't change the scaling here. 17:37:41 We do 5 smds per input, and 1 per layer per input *except for the last layer*. Assuming 8 layers... 17:37:48 (So 11 news, 12 smds actually, sorry) 17:38:21 ok will take a look at that 17:39:15 would like to get sign-off on helioselene-contest soonish too if possible 17:41:03 on general timeline, are we in rough agreement that we should wait for the contest before auditing? 17:41:30 I think so 17:41:56 and also does anyone have thoughts on the general fund for this contest? sounds like I'm the only proponent of that here 17:42:17 If everything else is audited, and contest results are over a month out, I'd advocate auditing as-is 17:42:35 I would prefer that XMR from the General Fund be used for the contest. 17:42:47 I also think "Why not" 17:43:54 sounds sensible to me too. of course, it's easy for me to support the spending of others' money :) 17:44:10 Eh, it's kinda up to core and we don't have too much say even as the respected community. I also don't know the current balance of the fund so I can't advocate any fiscal policy regarding it 17:44:20 "If everything else is audited, and contest results are over a month out, I'd advocate auditing as-is" -> this seems reasonable to me. In this case, I would likely re-work wallet side tree building which would take me a couple weeks 17:44:58

I could spear head that and look into our options. We have a long list of researchers on moneroresearch.info who I could reach out to and gauge interest. 17:45:30 Let the IRC record show that "I would prefer that XMR from the General Fund be used for the contest." was up-thumbed via Matrix emoji reaction by tobtoht , chaser , SyntheticBird , jberman , xmrack , and rottenwheel 17:45:35 As of last month, the GF has 15,747 XMR: https://www.reddit.com/r/Monero/comments/1iixgk9/monero_general_fund_transparency_report_february/ 17:46:09 if Core overall is against it, a compromise could be an agreement to a retroactive funding CSS. 17:46:30 Proposed prizes total 350 XMR, so about 2% of the fund 17:46:54 thanks Rucknium, it's easy to forget that reactions aren't preserved for the current historical record 17:46:58 IMO binaryFate would be the one to contact about using the general fund 17:47:29 I don't think we can offer a prize we don't have, unless you mean to replenish the GF? 17:48:28 kayabanerve yes, that's what I was thinking of. the GF in that case would serve as someone who loans the funds to the contest. 17:49:28 Thank you for the clarification :) 17:51:37 We are 50 minutes into the meeting. Let's move into the second business item unless there is something urgent left to discuss on this one. 17:52:39 Summing up updates on the contest: 17:52:39 - rough agreement here to request the GF cover the contest 17:52:41 - I'm requesting review on helioselene-contest 17:52:43 - I'll make changes to ec-divisors-contest in line with kayaba's suggestions 17:52:45 - @xmrack willing to take on marketing the contest :) thank you 17:53:07 4) Release of OSPEAD HackerOne and CCS milestone submissions. https://github.com/Rucknium/OSPEAD 17:54:10 plowsof was able to reproduce the small simulation on his own machine, with a few bumps in the road: https://github.com/Rucknium/OSPEAD/issues/1 17:54:51 Here is the draft getmonero.org blog post: https://gist.github.com/Rucknium/e18c514f0ba7a6dc6c7f35f9c242a34a 17:58:50 I am currently working my way through the OSPEAD release. 17:59:37 Maybe this agenda item can be combined with the next one, which is "Possible intermediate hard fork before FCMP hard fork. ofrnxmr , xenu , elongated " 18:01:08 does it need to be a hard-fork? could it just be a new release branch forked from master that is still compatible with 0.18 ? 18:01:19 I was going to mention this. It is actually the kind of feedback I got from my interview on the Crypto Show. 18:02:13 There is a case here depending on the timeline for FCMP++ to be active on the main chain 18:02:29 vtnerd: No, but a hard fork would be "safest" because they you don't have anonymity puddles where some users/wallets update to the new decoy selection algorithm, and others do not. 18:02:55 I was surprised to read about this initiative. is there have time for it without causing any delays to the FCMP++ fork rollout? 18:03:16 Hmmm. But that all is anyway only up to the FCMP++ hardfork 18:03:23 Regarding the concern about a small number of users updating; would a gradual migration of the DSA significantly mitigate the issue? An example might be to select x/15 decoys from the new distribution, with x = (blocks past the update)/10000 ? My naive assumption is that shifting the decoys slowly over a period of time would prevent people from immediately standing out, giving the 18:03:25 user base time to adopt the new DSA. 18:03:27 s/have// 18:03:29 if the hardfork is for decoy selection algorithm, its unlikely it can be enforced by any consensus rules 18:03:36 One can increase the ring size and implement the scaling changes as well as apply OSPEAD 18:03:42 I'll quote myself from before the meeting: 18:03:43 > The problem with partial userbase upgrade is anonymity puddles. for example, according to my calculations in https://github.com/Rucknium/misc-research/blob/main/Monero-Fungibility-Defect-Classifier/pdf/classify-real-spend-with-fungibility-defects.pdf , if only 5% of users upgraded to the OSPEAD decoy selection algorithm, the attack success probability against them would be 32% ( assuming perfect classification by DSA), actually higher than the 23.5% attack success against the current DSA. That would be a net loss in privacy. 18:04:21 Actual issue to raise. Can hardware wallets sign a ring size 100? Such a signature would be >3 KB. I'd also ask for 64 but would guess 32 is fine. 18:04:38 I say 100 to make the issue clear. 18:05:08 I wouldn't dare dragging any hardware wallet issues into any possible intermediate hardfork ... 18:05:22 My advocacy is to push FCMP++ through rather than spend time here. 18:05:23 I really match the future FCMP 2 in 2 out TX size 18:05:31 We want them spend time on implementing FCMP++, IMHO 18:06:15 The timeline for FCMP++ is important here. 18:06:17 ArticMine: I don't think HWW can do that without chunking the proof. 18:06:33 I am more or less with kayabanerve here: An intermediate hardfork could become an unwelcome distraction 18:07:04 spackle: Interesting idea. Yet, we don't have a good idea how quickly the ecosystem updates. With more effort, we could get an idea from historical instances (e.g. the 2021 decoy selection changes). 18:07:06 Very good point 18:07:26 And hay, it may sound harsh, but we are living for so long with those badly selected decoys, what is half a year more? 18:07:46 Libs are done besides audit responses and a couple of raised API issues. I'm starting solicitation for the next spread of audits. 18:08:10 Where is CARROT and integration? 👀 18:09:04 jberman and I are hard at work in the integration mines 18:09:50 Sorry it is just a slog 18:09:55 But, IIRC, isthmus commented to me that he does not see good value in trying to use estimates of historical adoption pace to forecast a future one for a DSA change without a hard fork 18:10:02 I just used the CLI to make a FCMP++ tx, so progress is good 18:10:14 But such a gradual migration wants to be coded and tested, that would eat dev hours, and make things more complex 18:10:41 Half a year does not justify two hard forks. A year is a different question 18:12:29 it's impossible to predict with high certainty how quick the adoption would be. with the potential for anonymity puddles, it seems like a risky endeavor. 18:13:03 How's the protocol changes? Ideally minimal, with y'all suffering on the wallet? 18:13:27 Without a HF for something else we can't implement OSPEAD 18:13:57 Really? A simple dummy version change for some important struct, done? 18:15:11 The only question I see here then is: How far can we push the existing proof in ring size without starting to break things 18:15:21 I'm personally spending a lot of time on tx construction with our current flow as well as planning a solid base for future work, like multisig and HW wallets. Pruned transaction format didn't actually change that much for Carrot/FCMP++, we just have a new variant for `cryptonote::tx_out`. The prunable transaction format is changing a lot though. Most of the protocol work AFAIK is the curve tree implementation, which is pretty hairy 18:15:44