15:02:04 MRL meeting in this channel in two hours. Anyone with a matrix.org homeserver Matrix account want to say here that matrix.org users sometimes cannot see all messages here, but we can see them? And to read invisible messages by refreshing https://libera.monerologs.net/monero-research-lab 15:08:57 reposting from IRC incase matrix dot org cant see .... 15:09:01 MRL meeting in this channel in two hours. Anyone with a matrix.org homeserver Matrix account want to say here that matrix.org users sometimes cannot see all messages here, but we can see them? And to read invisible messages by refreshing https://libera.monerologs.net/monero-research-lab 15:15:49 nioCat: Thanks, but AFAIK when matrix.org users cannot see monero.social messages, they cannot see IRC messages either. The IRC relay is a monero.social user. 15:41:53 That's also my understanding regarding IRC, sadly it seems to help only if you leave Matrix aside for the moment and "step down" to IRC, with an IRC users, if your Matrix user is on matrix.org. In Monday's wallet group meeting we more or less all ended up on IRC ... 17:00:40 Meeting time! https://github.com/monero-project/meta/issues/983 17:00:51 1) Greetings 17:01:02 Hello! 17:01:05 Hello 17:01:16 Hi 17:02:36 hello! 17:03:29 2) Updates. What is everyone working on? 17:03:32 Hi 17:03:39 Hi hi 17:04:13 me: More analysis of the suspected spam. I think I can push the new draft by the time we get to the spam agenda item 😅 17:04:27 Hi 17:05:31 Working on a monitoring software for monero nodes. I'll use it to build a dataset on which I want to train a neural network to identify network anomalies. This will be part of webpanel idea I had for a little while 17:06:27 me: finished reviewing @jeffro256 's PR to write txs to disk once instead of twice on sync (https://github.com/monero-project/monero/pull/9135), and wrapping up the Seraphis lib async scanner to speed up wallet scanning another ~20-40% 17:06:59 Working on fees and scaling. In particular to support FCMP and ring sizes of 40 or higher 17:08:01 Along the lines of what I mentioned before. Also taking a close look at minimum node relay fees 17:08:27 3) Update from CypherStack on Bulletproofs++ Peer Review: https://ccs.getmonero.org/proposals/bulletproofs-pp-peer-review.html 17:08:43 That's us! 17:09:01 Progress continues. Things are going smoothly. We expect to complete this proposal by the end of the month. 17:09:23 0xFFFF has paused his current ccs for the foreseeable future (he is working on the lmdb read/write lock PR, so just wanted to share for visibility) 17:12:15 In a few days then? Splendid. 17:13:12 We're nearly finished with the report, yes 17:13:38 It will no doubt require some additional polish after that. I would be shocked if it were free of typos :D 17:13:53 Hoping for a positive outcome of course, i.e. that it will indeed make sense for Monero to switch to ++ 17:14:13 Were you able to figure out if the security proofs were sound? 17:14:51 You can wait if you want, but I thought maybe you wanted to be on the agenda to give more details :) 17:15:10 We still have doubts based on a significant lack of clarity and some of the "base" results 17:16:21 When the full report is released I may have to figure out if "doubts" is a diplomatic way to say that the soundness proofs are not clearly safe. 17:16:39 "Base" = lemmas in the paper? 17:16:46 We haven't identified any particular exploits, if that's what you mean. 17:17:25 Generally, the idea is that the proof should convince the reader about the correctness of its reasoning. I will certainly say that several of the proofs in the preprint did not do that for this reader. 17:17:42 That's not really what I mean, but a conjecture is still unproven even if no counterexamples have been found yet. 17:17:43 For some we were able to determine the actual intent and make corrections, but for others we were not. 17:17:53 Can you be more specific? 17:18:22 I do want to be clear that "this proof does not appear to substantiate the claims to our satisfaction" is certainly not the same as "the protocol under question is definitively unsafe" 17:18:37 I think you answered my question with "Generally...". Thanks. 17:18:57 I was particularly concerned with the lack of clarity around a key soundness proof 17:19:09 There is a certain amount of diplomacy here, yes. :P 17:19:13 The idea is that the proof needs to build an algorithm called an extractor that has to do very specific things 17:19:39 In this case, the proof is extremely informal about this, without detail that convinces me of its construction 17:20:09 You will also find the word "presumably" in many places in the report, where we had to make assumptions about intent 17:20:38 I'm certainly not trying to be wishy-washy here. Just professional and accurate. 17:20:58 This all also seems to confirm something you mentioned last time, that things are considerably more complex compared to "+". IMHO, that doesn't help either 17:21:29 Yeah, the second "+" in the name carries a _lot_ of weight 17:22:04 We will already have a quite a serious step up in complexity with Seraphis and Jamtis. 17:22:26 What are the advantages of ++ in terms of size and verification time? 17:23:49 The authors claim single-proof verification time with BP++ (over secp256k1) at 0.840 ms 17:24:09 whereas for BP over secp256k1 they saw 2.223 ms 17:24:24 (There are other numbers for other implementations, but those are really hard to compare fairly) 17:24:55 They also get single proofs at 416 bytes, compared to BP+ at 576 bytes or so 17:25:49 I do have one question that wasn't directly addressed. Typically such a review will issue findings and corrections as appropriate, which is what our report does. But it's obviously not a pass/fail sort of thing (though I have seen this before...) 17:26:09 Is the community looking for something more cut and dry as a top-level sort of thing? 17:28:34 IMHO, cryptographers on the MRL end should give their interpretation of the final report instead of you needing to summarize it like that. I think I caused some confusion by saying "unsafe". I meant that something that is not definitely proven is not safe enough for Monero mainnet, even if it is not definitely proven wrong in the mathematics meaning. 17:29:32 In other words I don't think you need to put FAIL in bold red letters at the top. Or PASS in bold green as needed. 17:29:52 Rucknium: I would agree that Monero-specific interpretation should certainly be left up to community researchers 17:30:02 And no, there will not be a big red or green stamp at the top =p 17:30:13 This can be a tough question. In my view we are looking at an incremental improvement vs what I see as serious concerns regarding the proofs themselves. 17:30:15 (I saw one audit that did issue a pass/fail, and was immediately suspicious...) 17:31:07 And anyone who has gone through journal- or conference-style review surely knows that three different reviewers may have three wildly different conclusions 17:32:11 "I will certainly say that several of the proofs in the preprint did not [convince the reader about the correctness of its reasoning] for this reader" -> I think this is a reasonable conclusion and a report that backs up that conclusion in its contents would be satisfactory, rather than a PASS/FAIL 17:32:48 I agree this is not a pass / fail question, but the benefit of doubt has to be with the reader and auditor not the prover. 17:32:48 In the case of doubt or concerns it becomes a fail 17:33:15 For inclusion into the Monero code 17:33:48 We do certainly hope that the authors can find value in the report too, to make corrections and improvements as they see fit 17:33:49 What about BP+ verification vs BP? 17:34:03 I agree. The stakes are very high. Any real doubts would mean not adopting it into Monero mainnet IMHO. 17:34:38 Reuben: they include numbers for that, but it's with different implementations over different curves. Not comparable IMO 17:34:59 🥲 17:36:27 In terms of raw numbers, I can say that at least one BP+ implementation (in Rust over Ristretto) is likely comparable to their BP++ implementation. But I haven't tested their benchmark on the same machine 17:37:00 Unless you're using the same curve library and fair optimizations between implementations, it's a crapshoot to make claims about raw numbers 17:37:26 +1 based on that conclusion, it would seem ideal next step would be to share the final report with the authors and see if able to fill in the gaps / beef up the proofs 17:37:30 Oh Reuben maybe I misread... you weren't asking about BP++ at all? 17:38:12 Yes. I agree. 17:38:24 @jberman: How would the community like that handled? 17:39:22 It's always been the plan to release the report publicly and let the original authors know about the report. But we don't want to send and wait for their response before delivery. We also don't care to dictate how the whole process is handled. 17:39:31 Was just thinking if BP++ isn't a significant improvement over BP+ then I mean with the risks of BP++ doesn't seem to justify pushing too hard into it 17:39:48 Oh OK, you were asking about BP++ vs. BP+. Got it 17:39:58 (too many BPs floating around...) 17:41:03 FCMP currently uses BP only yes ? 17:41:28 "It's always been the plan to release the report publicly and let the original authors know about the report." This sounds fine to me. There is no need to wait for a response from the original authors. You've already contacted them about a few things anyway IIRC. 17:41:30 Forgot if we found a solution 17:41:34 Yes. To my knowledge, no one has used BP+ or BP++ arithmetic circuit modifications for that 17:41:42 original plan laid out by @diego makes sense. I think we can assess next steps after that point 17:42:02 Rucknium: We contacted them about a couple of initial findings, but nothing beyond that. We hadn't heard back from our latest question 17:42:19 I see things similarly to jberman 17:42:30 As a courtesy, we would certainly like to inform them directly to let them know about the report and where to read it 17:42:37 In my opinion this comes down to the allocation of resources. For example are we better off coding parallel processing and graphics processing with the existing proofs to get the verification time advantage? 17:42:37 I know I am thinking as an engineer and not a mathematician. 17:43:03 Development is likely to be quite complex compared to BP or BP+ 17:43:22 For BP and BP+, range proofs work differently than the more general arithmetic circuit proofs they also support 17:43:41 For BP++, you basically need the full arithmetic circuit proving system implemented 17:43:42 IMHO the recent suspected spam has exposed a lot of cracks in the network that better engineering could patch. And some cracks that need better math or something. 17:44:02 And that doesn't account for optimizations needed to presumably get the numbers they saw 17:44:07 To be fair, they do have a reference implementation in C over secp256k1 17:44:36 Regardless of the report findings, I think it's safe to say that a complete from-scratch implementation would pose nontrivial engineering risk in itself 17:44:58 Yeah, we definitely won't run out of important work soon, so with these shadows of doubts over BP++ ... 17:45:20 I'm certainly not trying to influence any decisions here. Just wanted to provide my best assessment 17:45:34 For a marginal benefit 17:45:40 Other reviewers may have different conclusions 17:45:51 ArticMine: the proof size difference is impressive 17:46:28 From a verification perspective, tough call. Batch verification is already pretty snappy, and it's not clear at what point the returns from that become diminished compared to the rest of transaction/network operations 17:48:39 Anyway, it sounds like the final report should be publicly delivered to the community? And then we can inform the authors directly as a professional courtesy? 17:49:31 Cool. Can we move on to the next thing for Cypher Stack? 17:49:48 Aaron Feickert: Thank you! Tremendous work. Extremely useful. 17:49:59 Yep, that sounds great to me 17:49:59 +1 17:50:04 Thanks! Sorry to take up so much meeting time on it 17:51:27 Diego Salazar: Yes, you can move to the next CypherStack item. 17:51:37 Thanks. 17:51:57 Given that we're almost done with this proposal, I'd like to discuss the possibility of the next one. 17:52:10 BP# 17:52:18 We've been asked by a few MRL individuals what it would mean to do a Seraphis review. 17:52:39 Before we give a quote and time estimate, I'd like to discuss with you all hear what exactly you'd want out of such a review. 17:53:02 Are we looking to formalize Seraphis? A holistic review? 17:53:14 Uh, I think the word "exactly" here will prove to be tough :) 17:53:19 Can jberman give the current status of the Seraphis paper? 17:54:04 The critical cryptography is Seraphis needs to be proven. I don't know what the journey there looks like. 17:54:57 The last thing I heard about the paper is that it is missing a few proofs at least. The entity that writes the proofs cannot be the one who peer reviews the proofs IMHO. 17:55:10 It had previously been my recommendation that a holistic review is more likely to provide practical benefit and return than a more exploratory formalization 17:55:53 So holistic review means basically figuring out where it needs work and maybe a plan to get it to finalization? 17:56:36 If the cryptographers in MRL want Seraphis to move forward, they need to move it forward. I'm not the best person to move it forward. 17:56:40 It would mean considering its security properties more informally, but from a more practical perspective than a strict security model and formalization 17:57:16 ^ This is not aimed at CypherStack, but at other MRL people 17:57:19 Seeing as developing a security model after the fact (or trying to use an existing one) may not prove fruitful, and still may not capture all practical risks and threats 17:57:49 Could it be said that with a "holistic review" you will "read and think the whole thing through, to find any possible problems"? 17:58:12 Are you familiar with the paper that formalized Monero's current security model? 17:58:29 One reason for my recommendation is also that the worst-case scenario for a formalization engagement is "we were not able to develop a security model that is amenable to the design", whereas the worst-case scenario for a holistic review is "here are findings and recommendations" 17:58:52 I recall seeing it, but at the time hadn't reviewed it in detail 17:59:04 Trying to hunt it down... 17:59:23 https://eprint.iacr.org/2023/321 "A Holistic Security Analysis of Monero Transactions" . It even has "holistic" in the name :P 17:59:41 Cypher Stack has been engaged in the past to do non-security-model protocol reviews. And we've certainly provided findings. 17:59:48 AFAIK it will appear in EUROCRYPT 2024 17:59:52 Rucknium: that's it, thanks 18:00:14 Rucknium: keep in mind that AFAIK, reviewers are not required to even read security proofs for that conference 18:00:21 I forgot about the meeting, sorry. Still working on LWS remote account scanning 18:00:31 And this paper is huge anyway 18:00:49 87 pages 18:02:28 There are some aspects of its security definitions that would need modification for Seraphis 18:02:38 and are fairly specific to Monero's RingCT 18:02:47 rbrunner: IMHO you or someone you are working with needs to guide the way on Seraphis formalization. I will not push it forward since it is out of my area. 18:02:59 @rucknium the Seraphis paper sketches a rough informal security model in section 1.2 that's light on details and the Seraphis tx protocol does not have formal security proofs 18:03:32 Thanks, jberman 18:03:38 A holistic review with an eye toward laying groundwork for a formalization of the protocol I think seems a solid route based on @aaron 's recommendations 18:03:54 I am pretty innocent regarding all things crypto, I wouldn't put much hope that I can really advance something here, even if I wanted 18:04:35 I suggested you since you are semi-official Seraphis project manager. 18:04:44 If a way is not found to formalize security, what then? Afaik some aspects of seraphis are hard to prove 18:04:59 I see. Yeah, for dev work, mostly, at least so far 18:05:13 If the Seraphis programmers want Seraphis on mainnet, they must get the math arranged. 18:05:30 One example of where formalization often comes up short is something like the mempool... this bit an initial iteration of the Spark design, whose security model didn't capture it. I _think_ this linked preprint similarly wouldn't capture it (but am not 100% sure on this) 18:06:10 @jberman: Right, an initial holistic review could certainly be done with an eye for future formalization 18:06:11 Probably mempool is out of scope IMHO. 18:06:31 Rucknium: ah, I'd disagree. That's how you get things like certain types of burning attacks 18:06:44 Alright, would you like us to draft up a proposal for a holistic review? All things considered, it seems the logical first step on this Seraphis journey. 18:06:51 and is why protocols like Seraphis and Spark need to account for different structural components in transactions 18:06:58 Aaron Feickert: Thanks. I didn't think of that. 18:06:59 I think a first rough estimate how such a "holistic review" might cost would help to decide. 18:07:11 Anyway, I would have a few questions regarding scope. Namely the following 18:07:21 Lacking knowledge but since each methods have requirements for seraphis to be mainnet. Having a holostic and formal review seems like a necessity 18:07:46 1. There are two papers on Seraphis: a general structure one, and an implementation-focused one that instantiates the protocol. Which should be in scope? 18:08:24 2. I know JAMTIS has been under design for a while, and it's included in Chapter 8 of the implementation paper. Is it in scope? 18:09:02 3. There are "information proofs" useful for proving various things about addresses and such to a third party, and they're in Appendix A of the implementation paper. Are they in scope? 18:09:07 (these are not security proofs) 18:09:27 4. Are there other specific or general scope items we should consider? 18:09:29 The general structure paper is the paper in scope (the implementation-focused one is there as a helpful resource) 18:10:14 that should answer all 4 q's :) 18:10:18 @jberman: Am I understanding right? "Implementing Seraphis" is _not_ in scope? 18:10:37 If anything, I would have thought the opposite for a holistic review 18:11:55 Perhaps one followed by the other? 18:13:37 hmm, a holistic review of the first paper I don't think should take too long in that case 18:14:18 True 18:14:41 Findings from it could be relevant to the implementation (if in fact the implementation is a proper instantiation of the general design) 18:15:02 But it obviously wouldn't capture anything specific to the instantiation, like JAMTIS or other particular components 18:16:01 I think doing things in a stepwise fashion gives the community the most bang for its buck 18:16:22 That's fair. But any reason not to jump right to the implementation paper? 18:16:39 It's much closer to what would actually go into a deployed implementation 18:16:40 The odds are very small, but if something is found in the general paper that makes the community rethink Seraphis entirely, it's helpful that they haven't already raised the funds for the instantiation paper 18:16:51 @Diego that's fair 18:17:04 Isn't it incomplete just for the general design? Since there are various ways to instantiate seraphis with different security implications no ? 18:17:54 Also assuming this doesn't include FCMPs either ? 18:17:58 @Reuben: Yeah, any specific instantiation would have security and design aspects specific to it 18:18:14 JAMTIS is probably the biggest example 18:18:44 Would it also affect security proofs ? Different instantiations have different proofs too no ? 18:19:25 The best way to look at it would be that different components (_e.g._ a range proof, a membership proof) need particular security properties proven for any particular choice 18:19:43 But ideally you build the overall security model such that things are as plug-and-play as possible 18:19:57 So you get something like "assume a range proving system with security properties X, Y, Z" 18:20:09 I figure a review of the first paper could clarify areas in which it needs strengthening, and would be specifically helpful in laying a cleaner path toward formalization and structuring a security model 18:20:11 You still need to pick a range proving system and prove those properties 18:20:43 @jberman: Although I do wonder how many findings could be addressed simply by "read the implementation paper" =p 18:22:05 Alright then. Aaron Feickert we'll first make a proposal for the first paper. 18:22:06 Anyway, we can certainly do an initial review of just the general design paper 18:22:24 And then explore further options once that's complete. 18:22:41 It does provide a quicker stopping point in the event of major findings 18:22:57 But the paper is significantly general that, TBH, I would be surprised (as @Diego notes) if this were the case 18:23:21 and it's far more likely that relevant findings would exist for the implementation paper, where the nuts and bolts live 18:23:40 Just want to make sure that expectations are set appropriately, given the structure of the papers 18:23:40 Alright. Then I think that we here at Cypher Stack have our marching orders. 18:23:59 I figure the first paper would be the first thing to review before reviewing the implementation paper anyway 18:24:31 I think the best way to look at it would be the following 18:24:57 A "positive review" of the first paper could basically say "there exist Seraphis instantiations that are likely secure" 18:25:20 Whereas a "negative review" could basically say "no Seraphis instantiation meets this informal security goal" 18:25:52 Any more specific conclusions would depend on the implementation paper, which could certainly be a follow-up engagement that I'd be excited to do :D 18:26:33 So I'll get information to @Diego for a proposal ASAP 18:27:01 Great! Nothing else for us then? 18:27:08 Thank you, Diego Salazar and Aaron Feickert . Please put suggested milestones in the proposal if you want them. 18:27:49 Thanks everyone 18:28:01 * m-relay hops out of the meeting 18:28:01 sounding reasonable to me 18:28:18 Thanks everyone 18:28:35 We are past the hour. The suspected spam is still a topic: https://bitinfocharts.com/comparison/monero-transactions.html#3m 18:29:22 I will just post a few more plots. The spam looks like it stopped recently. May be temporary. So, mean effective ring size is rising: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/images/empirical-effective-ring-size.png 18:30:00 I compared current suspected spam with the Chervinski et al. (2021) simulations: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/images/effective-ring-size-binomial-pmf.png 18:31:23