15:06:19 meeting 2hr 17:00:02 meeting time https://github.com/monero-project/meta/issues/727 17:00:02 1. greetings 17:00:02 hello 17:00:37 Hi 17:00:54 Hi 17:01:01 Hello 17:03:57 looks like a low-turnout day, might be a short meeting 17:04:06 2. updates, what's everyone working on? 17:04:44 I’m finishing up my final report for the magic grant which will be released Sept 1. 17:05:40 ooo123ooo1234567 posted an update on bulletproofs++ verification speed and it looks really promising for monero: https://github.com/monero-project/research-lab/issues/101 17:05:43 me: closed my previous ccs and opened a new one https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/338; started integrating tevador's mx25519 library into seraphis_lib to hopefully speed up the find-received scanning step (should have a performance test ready next week) 17:06:08 though I don't know what his plans are with the code now 17:06:46 OSPEAD work. Some research into possible methods to probabilistically classify on-chain transactions by their decoy selection algorithms, which would decrease effective transaction uniformity. 17:07:46 selsta: an almost 3x speedup seems too good to be true, looking forward to the code if/when it becomes available 17:08:22 UkoeHB: what part of the transaction verification is the bulletproof part? how would that translate to transaction verification? 17:08:47 iirc it's around half of the cost 17:09:35 me: I've been focused on wrapping up hard fork issues, atm specifically on more cleanly handling the case when an updated client connects to an older daemon and vice versa 17:10:28 I said last week I'd have a plan for moving forward with multisig to get it out of experimental but have been prioritizing the above. Will share my thoughts on it 17:10:34 ah looks like the batched verification isn't much faster in that test run 17:12:37 the speedup in proof construction would be a big win, making bps is really slow 17:14:21 3. discussion, anything to discuss? 17:16:01 jberman[m]: ? 17:16:12 Preliminary plan of action on moving multisig forward: 17:16:33 Open discussion with veorq with UkoeHB involved if willing, explain we'd like to get security proofs written for multisig and that our goal is to arrive at a well-vetted and safe multisig implementation that we are confident is no longer experimental. Will work together with veorq/koe to try to help explain the code so the security proofs can cover the entire multisig protocol 17:16:55 In that discussion, we'd discuss cost and time to completion estimates. Once we have a working framework established that is mutually agreeable toward achieving the above objective, would then look to funding 17:18:30 Sounds good to me 17:18:44 works for me 17:18:56 would these security proofs also apply to seraphis multisig later? 17:19:37 not directly, because there is a new proof structure 17:20:14 the new proof is basically a schnorr signature though, so existing multisig security proofs should be easy enough to adapt 17:21:46 ok, so we don't start with 0 again 17:22:40 So all multisig wallets need to get "dissolved" before the Seraphis hardfork? 17:22:57 rbrunner: no, I have a migration strategy 17:23:11 Oh, surprising 17:23:14 multisig groups just need to do one extra ceremony to migrate 17:26:04 jberman, at the last meeting you said "I think a change to the algo that would result in identifiable pools without a HF needs a very high bar to pass" I think it's possible to reduce the question to direct probability calculations, i.e. probability of correct guess of the real spend with current DSA vs. probability of guessing the real spend based on a probabilistic classification of the DSA that a given transaction is using in 17:26:04 a partial migration scenario. 17:26:19 Is such a comparison what you had in mind for the criterion? 17:27:28 rbrunner: https://github.com/UkoeHB/monero/blob/c822c7a90b18dfe5fa6c2f4661da85749f40bdb4/tests/unit_tests/seraphis_multisig.cpp#L144 this is account migration 17:28:06 Thanks, interesting 17:28:27 oh, and you'd need to update legacy multisig accounts so they can do aggregation-style signing on legacy enotes 17:28:35 that's on my TODO 17:31:12 I have found a few candidate methods to classify on-chain rings by their DSA. xmrack may have additional ideas. 17:32:50 If we have a high proportion of rings where the probability it's constructed by old DSA diverges largely from the new DSA, that would be a no-go imo 17:35:07 No-go until a hard fork, I assume? 17:36:13 right. unless we're certain there is some glaring issue that must be fixed 17:39:17 There is a glaring issue. The question you pose, which you're right to pose, is if the cure is worse than the disease. Anyway, I think it's probably possible to get a clear, fairly precise answer on that. 17:41:18 sgtm 17:43:11 I'm probably going to need more funding for that analysis though 😅 17:47:21 are there any other topics anyone would like to discuss? questions? 17:49:24 ok I'll call it here, thanks for attending everyone 17:53:02 selsta: there aren't many google hits for bp++, do you think we should hit up bunz's team and possibly some others to review the paper? 17:56:00 We could also ask the paper's author if he has submitted it for publication anywhere. 17:57:09 it would be great if ooo123ooo1234567 could clarify his plans on how to continue with bulletproofs++ now, he did say he spent time on checking security but i don't know what that entails 17:59:15 kayabanerve: Want to email the BP++ author and ask if it is under review anywhere? 17:59:31 otherwise we can either try to contact the paper author or like you suggested someone who was involved with Bulletproofs 17:59:48 quite sure the author of B++ works for spacex now 18:00:28 so no idea how available he is 18:01:18 How did you come across that info? 18:01:40 linkedin 18:01:52 i was curious what their background was 18:03:16 but that was a couple months ago could be outdated at this point 18:07:07 I will contact the bp++ author 18:07:47 UkoeHB: is batched verification the only thing relevant for us? 18:07:55 apart from generating proofs 18:07:56 Thanks. I didn't want to do it since I don't understand cryptography 18:08:42 selsta: also 256 byte smaller proofs 18:09:38 i meant solely regarding verification 18:10:33 either way it is a nice upgrade with basically everything improved 18:24:52 Does anyone know Sarang’s opinion on the BP++ paper? 18:26:48 he has not made any public comments on it that I'm aware of 19:41:19 UkoeHB: I took the liberty to post this: https://old.reddit.com/r/Monero/comments/wwso0y/contribute_to_moneros_future_support_koes/ 19:43:34 thanks rbrunner 19:44:30 Welcome. Thank you for you perseverance and still forging on :) 20:53:49 BP++ author says he's working on conference submission(s). He would like to see the BP++ code if possible 21:02:49 Good to hear :)