15:01:06 my weekly report: began to remove the MMS, after a chat with tobtoht, with the idea we can re-introduce it post FCMP++ 15:01:07 it is a little early to add context to the following 15:01:16 while working on multisig stuff, I noticed something that made me reconsider https://github.com/monero-project/monero/pull/9983 15:01:17 here is a little summary to not spam the chat https://paste.debian.net/hidden/b8cd2f7a/ 15:01:19 (ping reviewers: selsta 0xfffc ) 15:01:21 I'm very sorry for this mess 15:02:45 should we revert it for now? 15:05:15 not sure what is common practice in such a case, but I think that sounds reasonable 15:18:35 tobtoht would prefer a fix over revert if you have time 15:41:23 if I can get confirmation that this is the right approach I'll make a PR for master and another one for release 15:41:25 https://github.com/monero-project/monero/compare/master...SNeedlewoods:seraphis_wallet:x_fix_do_not_relay_for_submit_multisig_maing 15:42:34 i'd say open it and then people can add reviews 15:42:51 also add an explanation to the description 15:55:08 PR for master is done https://github.com/monero-project/monero/pull/9996 15:58:08 ty 16:22:16 please also open against release 16:59:36 Yeah, if the `submit` command does not submit, how do you submit at all :) A bit funny that the two reviewers of the original #9698 commit did not object. I guess they did what I also did first today to learn what this is about: Looking at the code to check whether it does what the PR claims. What I didn't do first is think whether the whole thing makes sense in the first place. 17:00:20 Meeting in 1 hour 17:09:36 I somehow thought it was meant to e.g. prevent a cold wallet from accidentally broadcasting, but I think for an actual cold wallet you use `offline` flag for this anyways, so the `do-not-relay` would only give you something like a "lukewarm wallet" in that case. 17:09:37 But definitely overlooked how the `submit_transfer` does it. 17:09:39 Just glad I found it while working on something else and it's fixed before it's causing problems 18:00:01 Meeting time. Hello! https://github.com/monero-project/meta/issues/1236 18:01:30 Hey 18:01:34 *waves* 18:02:48 Could be that message propagation is slow today? 18:02:55 Anyway, any reports from last week? 18:03:32 Howdy 18:04:26 as mentioned earlier "began to remove the MMS, after a chat with tobtoht, with the idea we can re-introduce it post FCMP++" 18:04:27 and worked on some more multisig related stuff in simplewallet 18:04:29 and also fixed an issue I created 18:05:00 idk seems normal to me 18:05:14 Mainly this last week has been the FCMP++ optimization contest. Have been poking and prodding those submissions, bench-marking, etc. j-berman and I are more or less decided, and will hopefully post our decision soon 18:05:42 With dediciding among how many submissions? 18:05:49 *deciding 18:06:02 me: depcrated scan_tx scanning *future* txs relative to the wallet's current sync height and merged the FCMP++ impl into the fcmp++-stage branch (github.com/seraphis-migration/monero/pull/49), re-continued local work on supporting high input FCMP++/Carrot txs, and as @jeffro256 said lots of FCMP++ optimization contest handling 18:06:49 I would guess 2 or 3 submissions? 18:07:38 5 distinct contestants (including the initial round prior to the deadline extension), and 1 contestant had multiple submissions 18:07:47 Wow 18:07:55 For the second deadline, there were 4 submitters, with one of them submitting 4 submission variations 18:08:17 So it became a true contest in the end 18:08:30 And one submitted 2 minutes before the deadline ;) 18:08:38 Lol 18:09:10 Yes absolutely, which made it pretty hard to judge honestly. Lots of good stuff 18:09:32 *"judge, honestly" ... *not* "judge honestly" lol 18:09:45 Understood :) 18:10:49 If that's it about the reports, I have a question, with the people in the know probably attending: 18:11:10 Somebody made a multisig related CCS proposal: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/595 18:11:30 As it looks to me, some serious work, for some serious money, 300 XMR 18:11:40 I wonder where we currently stand with Monero multisig 18:12:09 SNeedlewoods: You said you had a chat with tobtoht regarding this. Any interesting details? 18:12:47 Assuming it's ok to share them 18:13:36 tobtoht: "I've mostly lost interest in finishing it before the FCMP++ fork, given how brittle the current multisig implementation is." 18:15:50 The plan floated for some months now is to replace the current internal multisig impl (not high level impl) with kayabanerve 's impl as the backend for the FCMP++ crypto logic 18:15:53 my understanding of our multisig is slowly building up, but I still lack knowledge of many details and the great picture 18:16:37 Yeah, I know that there is something in the "Serai / Rust universe" of code, but does not know much more than that it exists 18:16:50 When I see big multisig projects like this, I wonder what the actual real-world desire for general-purpose non-enterprise multisig wallets is. RINO multisig was about as user-friendly as it gets, and it basically died b/c it had no market 18:17:30 That's of course a whole different question, whether there is demand at all. I am so far mostly interested where we stand on the technical side. 18:17:44 The main motivator was getting CCS funds in a multisig wallet to mitigate another hacking incident. 18:18:13 And yeah, general-purpose multisig in Monero is going to suck at a protocol level (no non-interactive balances) until Carrot-keyed wallets are availble on FCMP++ 18:18:38 Or some other bespoke FCMP++ alternative 18:18:44 Remember that. Do I get it that you did not give up on multisig, but you wait for better preconditions after the FCMP++ hardfork? 18:19:03 Yes. 18:20:07 How is that, will it be much easier to use additional Rust code like that alternative multisig implementation after the codebase became dual-language C++ plus Rust after the hardfork, and all the details about interfacing back and and forth are crystall-clear? 18:20:20 FROST would be nice for the CCS use-case since the secret shares are publicly verifiable IIRC 18:20:46 But that's incompatible with the multisig wallets in the reference codebase 18:21:31 Yes, there is the question whether we would have to keep the "old" multisig alive, for compatibility reasons. I tend towards "yes" right now 18:23:33 I'm of the opinion that future multisig developments should happen outside the core codebase NGL, as long as multisig is supported by consensus on a research level. There's so many different ways of doing multisig with different trade-offs, and like you say rbrunner7, once we do it one way, we have somewhat of an obligation to support it indefinitely so people's funds aren't lost 18:24:02 Tbc, IIRC, kayaba already does have crypto logic that is compatible with current multisig wallets that would also be compatible after FCMP++, so it's a matter of re-jigging the internal code to call the Rust 18:24:48 Interesting. Will the Rust multisig stuff be part of some code review? 18:25:52 https://github.com/cypherstack/frostlass 18:25:53 not sure if this is what we're talking about 18:26:53 this audit includes it in scope: https://ccs.getmonero.org/proposals/monero-serai-wallet-audit.html 18:26:57 It seems to link to the right repo 18:28:26 kayabanerve will probably have commentary / corrects / clarifications on this discussion as well fwiw 18:28:56 Good to know that it's included in that audit. After learning things here now, I stand by my comment below that CCS proposal: I don't think right now is a good time to throw 300 XMR at some multisig solution 18:29:59 I also dream there about a multisig workgroup that brings everything on the right tracks, with good project management and broad consensus :) 18:31:36 I am not sure how much of a precedent the demise of RINO is. That was an island of a solution, not some feature broadly available and interoperable over severaly important wallets 18:32:02 What I would imagine in the proverbial ideal world 18:32:55 But of course I readily admit that people can build whatever they like, and people can donate for what they like. 18:33:00 Hopefully, once the FCMP++ foundation settles, then Carrot key derivation schemes can settle, then FCMP++/Carrot/OVK-compatible multisig cryptography can settle, and then perhaps multisig messaging standards can settle, and then a good UX application ecosystem can blossom. But right now, IMHO, so much of the multisig plumbing is in flux... 18:34:37 IMHO we also need code that has broad support. I am afraid that something planned, designed and built by a single person, without seeking consensus first with the dev community, is in danger of dying if the original author does not carry it forward anymore. 18:35:27 Alright. Maybe comment at the CCS proposal if you feel like it :) 18:35:58 multisig workgroup sounds important for that 18:36:00 Exactly. This CCS may be successful in the short-term, but it WILL need sweeping changes in the medium-term, and it may not be good for other people's use cases, so some other may fund a parallel 300 XMR CCS proposal that fits *their* use case 18:37:37 With a standalone GUI program I wonder anyway how to avoid ending up putting more and more wallet functionality in there if it also has the job of making multisig transactions ... 18:37:53 At least that was my own reason to stuff everything into the CLI wallet, and *not* making a standalone MMS thing 18:37:54 Basically, I don't think that that CCS should be outright denied, but it needs more planning from the beginning so this doesn't happen: https://xkcd.com/927/ 18:38:22 I see that we dream along the same lines, jeffro :) 18:38:58 Our super-strong project management capabilities will save the day. Ahem. 18:39:59 Alright, nice to see where we stand with multisig. Anything else to discuss today still? 18:41:05 Does not look like it. Thanks everybody for attending, read you again next week! 18:41:43 thank you 21:51:52 The FCMP++ libraries, which will be in the Monero tree, already have multisig protocols defined for CARROT and legacy wallets. The sole requirement is a C++ binding. I see no need to advocate continuing Monero's existing multisig nor integrating Serai's CLSAG this time, though the transition to Serai's CLSAG would do the work for the transition to the FCMP++ legacy wallet multisig protocol