14:32:20 Meeting 2.5hr 17:02:22 oh meeting time 17:02:33 Hi 17:02:37 Hello 17:02:41 Hi all 17:02:45 Hi 17:02:47 https://github.com/monero-project/meta/issues/716 17:02:47 1. greetings 17:02:47 hello (sorry was working lol) 17:03:29 hello 17:03:50 Hello 17:04:35 2. updates, what is everyone working on? 17:06:14 I'm still working on writing the codes and explanations for bulletproofs. I took a week of vacation this month so I will be a about a week late to deliver my second working package. But everything is on track. :) 17:07:15 I think I have found a solution to all the challenges in my outline of the plan for OSPEAD. I think in 3-4 weeks I will have a document to submit to the "scientific review committee". If you want to be on that committee, let me know (subject to checks on substantial involvement in the Monero Project). 17:07:26 I talked to Ukoe and decided to tackle https://github.com/monero-project/monero/issues/7353 (update InProofV2 to V3) and after that implement UnspentProof as described in Zero to Monero. Will start work on it next week because I still have other things planned for this week, but will start getting the picture this week hopefully :D 17:07:28 I'm still scanning the blockchain too and haven't found anything suspicious (I finished the MLSAG era) 17:07:52 me: 1) simplified the grootle proof implementation in my seraphis library to be less generic (this makes it a lot easier to read and understand); 2) implemented a 'transcript building' system for seraphis, which at the very least makes writing transcripts a lot easier e.g. https://github.com/UkoeHB/monero/blob/ddc41c018cce347d9b6e8a319e0e5e1c47fe4764/src/seraphis/sp_composition_proof.cpp#L101 ); 3) reviewed the multisig audit 17:07:52 report from inference ag https://test.rino.io/rino-report-20220626.pdf (no major findings) 17:10:08 Rucknium[m]: are you aiming for that to be a public document? 17:10:53 (Also special thanks to kayabaNerve and plowsof for troubleshooting an issue with MoneroResearch.info 17:12:01 3. we can move to discussion 17:12:21 UkoeHB: Part of it is OK to be public immediately when ready. For other parts of it, that will be "to be determined". I think several people (jberman, isthmus, ArticMine) are leaning toward making everything public once a solution is estimated. 17:14:01 I'm thinking if we go full public, then I can submit it to IACR and/or something like PoPETs in some form. 17:14:05 Unless your research describes how to do an active attack on user privacy, there shouldn't be any problems with publicizing your work (since it will be public eventually, unless I'm mistaken) 17:14:38 It does describe such an attack. Well, a "passive" attack. 17:15:22 elaborate? an active attack means taking some actions on the network/chain 17:15:25 As in, observation of the blockchain data without an observer creating their own transactions. 17:16:11 ^ Did that clarify 17:16:18 if it's not an active attack, then anyone can do that analysis ex post (unless you need to collect network data that wouldn't otherwise be collected) 17:16:41 Yes, anyone could do it ex-post. 17:17:06 therefore, is there an advantage to not publicizing? 17:17:19 +1 I lean toward public. Even FloodXMR is an active attack and that should definitely be public 17:18:28 The main advantage to not publicizing is that it would not directly give chain analysis entities another tool in their toolbox. 17:19:05 Security disclosure is not my area of knowledge, so I would mostly defer to others on this. 17:19:27 are you implying it wouldn't eventually be disclosed? my question is about the timing of disclosure 17:19:50 I've never heard of research that wasn't disclosed eventually 17:20:48 Not sure, but I think we have a small number of Hacker One entries that to this day are not public 17:21:00 The benefit would have to outweigh the cost - in this case, potentially endangering a significant number of past transactions 17:21:10 It is possible to avoid disclosure, yes. The improved decoy selection distribution could be disclosed without the method of determining it also being disclosed. I know that in the past there have been severe "issues" with cryptographic primitives not having sufficient justification so as to enable "back-dooring". IMHO, these statistical issues don't work like that, but I understand why people have a concern, for sure. 17:22:07 It's a bit optimistic to think we can keep that secret for years, no? 17:22:08 rbrunner: sure, but did those lead to major code changes with opaque justifications? (guess it's hard to know for sure) 17:22:23 Perhaps the method could be disclosed a certain amount of time after the solution has been implemented 17:22:43 Main benefits: promote additional research into this area by publishing. Other people can examine my solution. Miantain "user trust" in the decoy selection algorithm 17:23:20 Main benefits to disclosure, that is ^ 17:24:27 The main argument for not disclosing up to now is that it doesn't make sense to disclose until we have a full solution ready to implement. But then we can re-open the discussion once we have a full solution. 17:24:49 sure I suppose that's fine 17:25:30 I would vote for disclosure and publication once a patch is proposed and verified 17:25:56 are there any other topics? any questions/comments on the multisig audit? 17:26:56 To be clear, the attack is probabilistic in nature. For many Monero users, a probabilistic attack is not relevant to their threat models. 17:28:57 'attack' might not be the right word, since it is just an analysis that exposes weakness in the decoy selection algo (to be a little pedantic :p) 17:29:53 UkoeHB: what are your thoughts on the optimal path forward with multisig from here :) 17:31:08 To continue...it is important that I have some -dev resources for OSPEAD implementation. There are still some questions about some things that are written in C++ in existing codebases. The current estimation method is slow and can be made faster with a C++ implementation. I'm wondering what jberman plans to do for his next CCS. Are you still interested in decoy work? I think mj-xmr is interested, but I wanted to see if others 17:31:08 are too. 17:32:26 at this point I'm fine with merging 8149, doesn't seem like we will get any more reviews or useful comments; would be nice to expedite a fix for the fund burning issue after that; can discuss it more at the dev meeting tomorrow 17:33:32 That's good news 17:34:02 But well, after basically 0 bad surprises from the review not merging would probably hard to defend 17:36:05 UkoeHB: SGTM 17:36:58 Rucknium: if mj-xmr is interested they can take it, but yep I'm happy to help/provide eyes/code on it where needed as long as it's settled it'll all be made public. I was thinking for my next CCS to be a month long to complete the background sync cache + do more PR review work 17:38:27 Right. Now I remember that a sticking point is you want to make sure that everything will be disclosed if you were to work on it, which is totally fair. 17:39:56 I am thinking that we will want about two months of post-hardfork data for the final estimation, by the way. 17:41:38 The reason to segregate post-HF data is because we'll be sure as we can be that everyone running the core wallet software will be running the latest algo? 17:43:00 No, although that helps a bit. We can't be sure that everyone will be running the wallet2 algorithm, but nonstandard ones should be less prevalent. I gave a reason to you and isthmus. 17:44:22 To be clear, on-chain nonstandard decoy selection algorithms will be dealt with in OSPEAD. 17:44:31 I would not mind seeing the reason. I have my suspicions 17:45:16 ArticMine: I will PM you. Would you like to be on the scientific review panel? I assumed you would. 17:45:32 Which I will not reveal publicly 17:46:02 Yes I am interested 17:46:13 isthmus said he is willing to be a "minor reviewer" 17:47:47 we are closing in on the end of the meeting; anyone have any burning questions to get out? 17:52:12 ok seems like we are done; thanks for attending everyone 17:58:53 thanks UkoeHB