15:04:20 MRL meeting in this channel in two hours. Aaron Feickert : will you be at the meeting for the CypherStack agenda item? https://github.com/monero-project/meta/issues/976 15:08:48 Rucknium: yep! 17:00:23 Meeting time! https://github.com/monero-project/meta/issues/976 17:00:45 1) Greetings 17:00:49 hi 17:00:52 Hello 17:00:56 Hello! 17:01:07 hi 17:01:24 hello hello! 17:01:44 <0​xfffc:matrix.org> Hi everyone. 17:02:11 hello 17:02:34 2) Updates. What is everyone working on? 17:03:31 me: OSPEAD. I think I will make my self-imposed deadline of next week for milestone 2. 17:04:29 me: working on getting LWS new accounts "pushed" to scan threads intead of resetting the scan state on new accounts 17:05:00 also was tracking a LWS bug someone reported privately via telegram, but was unable to duplicate (segfault) 17:05:51 <0​xfffc:matrix.org> Me: worked on second version of reader_writer lock 9181 which addresses writer starvation issue. It is finished, and in a good shape. I believe with few reviews and a little bit more testing we will be able to get it merged. I am running it on my private node too. 17:06:30 3) Discuss: CypherStack have requested 50% ($16,000) of the Bulletproofs++ Peer Review CCS to be paid out. https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/358#note_23485 17:07:03 Hiya. I brought this up at the community meeting too. 17:07:19 Aaron Feickert: Could you say something brief about the review progress. I heard that you found some flaws in the security proofs, but you were able to repair some(?) of them 17:07:55 Basically we're more than halfway through and the singular milestone is kind of set up to only pay out at the end. Given the length of the project, it'd be very helpful to us to be able to have a mid payout to keep some cash flowing. 17:08:16 Aaron can answer specific questions, but our progress report is basically the following: 17:08:39 We've made significant progress. Lots of math. Lots of digging. Found some errors so far. Talked to the authors who responded. Still more to work through. Got like 11-12 pages of math so far. 17:08:59 We DO have a VERY incomplete draft of the paper for viewing if people want proof of work. Just what we've done up to this point. 17:09:25 Aaron Feickert: if you wanted to give a very brief statement about security proofs and authors as Rucknium asked? 17:10:48 Yeah, we've identified a number of issues so far. There's a fair amount of notation that's incomplete or incorrect, several points in the proofs that we needed to expand on significantly for correctness, one proof that was incorrect (and even had an incorrect statement) that we rewrote, and another whose validity we're still attempting to verify 17:11:15 I've been in contact with the preprint authors as well to discuss some of the issues 17:11:54 "incorrect statement" == theorem is wrong? Do you have a counterexample? Is it an important THM for the paper? 17:13:01 To me it sounds like we will need another party to do another review of your work because the changes are large. That's fine. It affects hard fork planning. 17:13:01 The particular lemma is at the heart of higher-level emulation claims. The statement of the lemma was incorrect: it couldn't possibly have held, didn't match the proof (which had other errors), and wouldn't have made sense for the emulation 17:13:16 The authors agreed, provided the actual statement, and we rewrote the proof to assert it could be fixed (it can) 17:14:12 A lot of the preprint is written fairly informally, unfortunately, in terms of things like notation and claims. This makes it challenging. 17:15:06 How does that compare with earlier Bulletproofs and Bulletproofs+? 17:15:23 I mean, do you happen to know whether the papers were better? 17:15:28 That's an excellent question 17:15:59 Roughly speaking, I'd say that BP and BP+ share a lot of the same underlying structure, and the way the range proving protocols are built makes analysis reasonably straightforward 17:16:12 Thanks so much for your work on this. I don't like to set precedent for splitting milestone payments, but your CCS proposal only had one milestone. Most proposals have multiple. I think it would be OK to pay half the milestone if we get your current draft. 17:16:23 The extra "+" in BP++ carries a lot weight; the structure of its range proving protocols is _very_ different and _much_ more complex 17:16:34 *a lot of weight 17:17:06 FWIW, BP+ had a flaw in one of its math proofs. It was caught and corrected in one of Monero's reviews. 17:17:21 Yep 17:17:54 I think the precedent would not be a big problem if we try to find points for mid-way payout in future such CCSs to avoid the issue in the first place 17:18:19 For big reviews, that is 17:18:52 Anyway, as Diego Salazar mentioned, we have an in-progress report (around 11-12 pages) 17:19:15 I would caution against making it widely available, lest readers assume more from it than they ought 17:20:24 My gut says that the benefit of BP++ might not be worth the risk. We "only" get smaller tx sizes and faster verification. But if we're wrong then a malicious actor can create counterfeit XMR. Too early to say for sure now while the review is ongoing of course. 17:20:39 Just curious: Will BP++ continue to be used in a FCMP version of Monero, if it comes to that? 17:21:18 If you don't want the draft widely available, then maybe write a summary of initial findings? That wouldn't take much time, right? 17:21:40 Rucknium: how detailed would you like such a summary to be? 17:21:58 No. The draft is ready to go and the work has been done on it already. 17:22:03 I am not a cryptographer, so ask one :) 17:22:04 @rbrunner: I am not certain how much work would be needed to modify the BP++ protocols to support that 17:22:21 1 - 2 pages summary I assume would cover things 17:22:51 Rucknium: the risk assessment is tricky, to be sure, given the complexity 17:23:14 There are a lot of new moving parts to BP++ 17:24:14 I'm sorry to be a choosing beggar here, but I'd rather not spend a few hours of unpaid work on a summary. 17:24:25 I was skeptical of this paper from the beginning. Take my skepticism with a grain of salt :) 17:24:47 Rucknium: all math should be subject to healthy skepticism :D 17:25:01 Happy to share the draft we prepared yesterday as proof of our work. If a summary is needed for release of half the funds then we'll push forward without it until completion. 17:25:28 Not trying to be hostile or antagonistic. Hope my words don't come off that way. 17:25:31 The draft does contain a warning right up front about its incomplete status, and is thoroughly watermarked as a draft! 17:26:02 (This is common for Cypher Stack reviews, so there's no doubt about the draft status of initial reports) 17:26:47 If there are not vulnerability disclosure concerns with the draft, then we have to give something public to the community IMHO. It can be a summary or the current rough draft 17:27:01 Again, I would just caution any readers against assuming final conclusions from such a draft 17:27:14 We have a comment on GitLab from UkoeHB: "A short progress report may be appropriate, to justify adding a milestone" I guess he could do with a more detailed interim report as well 17:27:21 Showing the community isn't a problem, I don't think. I think the big issue is spreading it widely on social media. 17:27:38 Rucknium: I know of only one implementation, and I don't think it's deployed anywhere (or even assumed to be ready for deployment) 17:28:10 Yeah, I don't think social media will be a real problem :) 17:28:20 In this particular case 17:28:58 Readers should just be cautioned that the findings could change over time as the review continues, and as we continue discussions with the preprint authors 17:29:23 Where would be appropriate/sufficient for community? IRC channels? Telegram? Reddit? 17:30:05 Post on the CCS proposal as a comment IMHO. Any community members closely following the proposal will see it 17:30:06 Perhaps the gitlab discussion itself 17:30:18 Yup, had the same thought 17:30:51 Anyone else in the meeting here have opinions about this? 17:32:15 Diego Salazar: "I'm sorry to be a choosing beggar here, but I'd rather not spend a few hours of unpaid work on a summary." That's totally understandable :) 17:32:22 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/358#note_23499 17:32:38 Also note that the preprint authors haven't been sent the draft 17:32:42 Yeah, I suppose the work turned out to be bigger than anticipated anyway 17:32:43 We've been discussing specific issues via email 17:33:11 You are aware that the paper was accepted at EUROCRYPT 24 right? 17:33:22 I was not! 17:33:29 By a lot. The proposal was first made when draft 1 was a thing and I didn't think much of the timeline. Then draft 2 dropped and it more than doubled the workload. 17:33:37 The authors didn't mention it, but I also didn't ask /shrug 17:33:39 Just clearly state it's a draft and summarise the content into bullet points with [draft] after each one? 17:34:00 https://eurocrypt.iacr.org/2024/acceptedpapers.php 17:34:30 sounds ideal. jberman / UkoeHB where the first to request. if they can give it a lgtm 17:34:35 Rucknium: interesting! How did you come across it? 17:35:01 Revise it and get coauthor credit ;) 17:35:02 kayabanerve saw it first 17:35:08 I'm intrigued as to what the EUROCRYPT reviewers thought 17:35:23 And then we discussed here the quality of peer review standards in cryptography 17:35:33 I will note that conference/journal reviews can be all over the place 17:35:46 *rubber stamp* 17:35:54 I've seen some that are really excellent, and others where I questioned if the reviewer read the whole paper =p 17:36:19 That's not to say their specific reviews were thorough or not thorough (I have no idea) 17:36:26 I can only speak for our review 17:36:47 Yeah if you all can go to the PR and give an emoji or something, that'd be great. :D 17:37:06 (Terrifyingly, I've seen situations where reviewers were not required to read security proofs) 17:37:30 Anyway, sorry to derail! 17:37:38 Yeah I quoted our conversation about that here in this channel. I hope that was OK. 17:38:02 (Side note: the EUROCRYPT program looks excellent) 17:38:20 That "accepted paper" list is fascinating for a crypto-noob like me: How much I have absolutely no clue about :) 17:38:44 pending emojis/lgtm from jberman/UkoeHB. it would seem that binaryFate should then go ahead and send out the payment when possible yes? 17:39:26 Sounds reasonable to me 17:39:35 Weee! Thanks all. 17:39:50 Well, depending on the emoji used of course 17:39:57 We do hope to have this completed this month, I believe. 17:39:58 Hopefully the giant DRAFT watermark is large and annoying enough :) 17:40:05 Thank you Diego Salazar and Aaron Feickert . Incredible work. 17:40:12 Given we are actually much farther than half way 17:40:20 Rucknium: thanks! I admit it's been a challenging review 17:40:50 But as always, I hope it's useful to the community and broader ecosystem 17:41:45 jberman: UkoeHB ^ 17:41:57 either way. Nothing else from us. 17:42:24 We had a couple more items of the agenda. jeffro256 isn't here now to continue the +1 alternative block tiebreaking idea. 17:42:55 We have had a x2 increase in Monero tx volume the last two days: https://bitinfocharts.com/comparison/monero-transactions.html#3m 17:43:11 2x increase in two days?? 17:43:20 the surge seems to have already subsided 17:43:37 Yes. Just checked, it's ongoing. They pushed blocksize up to 310 KB at one time 17:43:45 Some kind of obvious spam attack? 17:43:58 Anything stand out about the tx structures? 17:44:07 In the morning UTC it was a bit less. Now we have again 1039 txs waiting. 17:44:18 my node says there are ~880txs in pool now, 5 block backlog 17:44:21 geez 17:45:08 Mostly 1 in / 2 out as far as I can see, nothing extraordinary: https://xmrchain.net/ 17:45:10 lots of 1in/2out txs. We could try to run the same analysis that we did in 2021. But that's a lot of work. https://mitchellpkt.medium.com/fingerprinting-a-flood-forensic-statistical-analysis-of-the-mid-2021-monero-transaction-volume-a19cbf41ce60 17:46:07 could be a very naive exchange or pool doing payouts to 1 user per tx 17:46:24 when they should have been doing N destinations per tx... 17:47:59 txpool for convenience: https://xmrchain.net/txpool 17:48:34 holy mempool batman 17:48:54 plowsof and I are storing txpool data. This will help with fee prediction algorithms later. 17:49:11 I just check print_pool_stats on monerod ... 17:49:24 And other research questions we don't know about yet 17:50:09 If it is an attack, wonder if it's the same entity/entities as the earlier Zcash spam attack 17:50:15 That went on for quite some time 17:50:20 Anyone think I should divert effort to analyze this? I prefer "no"... 17:50:53 My first thought is "Depends on how long this continues" ... 17:50:59 I don't know what action could be taken. The dynamic block size is supposed to work its magic. 17:51:12 It's it's not magical, then it should be made more magical...but that has to wait for a hard fork 17:51:26 If it's* 17:51:37 monerod print_pool_state for convenience* web url so i look busy hyc** lol 17:51:52 stats* 17:53:39 Anything else? If not we can end the meeting. 17:55:27 --- end meeting --- 17:58:07 thanks for chairing Rucknium! 19:32:53 Thanks for the update Aaron, good to see the progress :) 19:35:08 @UkoeHB thanks!