<s​needlewoods_xmr:matrix.org> my weekly report: began to remove the MMS, after a chat with tobtoht, with the idea we can re-introduce it post FCMP++

<s​needlewoods_xmr:matrix.org> it is a little early to add context to the following

<s​needlewoods_xmr:matrix.org> while working on multisig stuff, I noticed something that made me reconsider monero-project/monero #9983

<s​needlewoods_xmr:matrix.org> here is a little summary to not spam the chat paste.debian.net/hidden/b8cd2f7a

<s​needlewoods_xmr:matrix.org> (ping reviewers: selsta 0xfffc )

<s​needlewoods_xmr:matrix.org> I'm very sorry for this mess

should we revert it for now?

<s​needlewoods_xmr:matrix.org> not sure what is common practice in such a case, but I think that sounds reasonable

tobtoht would prefer a fix over revert if you have time

<s​needlewoods_xmr:matrix.org> if I can get confirmation that this is the right approach I'll make a PR for master and another one for release

<s​needlewoods_xmr:matrix.org> github.com/monero-project/monero/co…not_relay_for_submit_multisig_maing

i'd say open it and then people can add reviews

also add an explanation to the description

<s​needlewoods_xmr:matrix.org> PR for master is done monero-project/monero #9996

ty

please also open against release

<r​brunner7:monero.social> 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.

<r​brunner7:monero.social> Meeting in 1 hour

<s​needlewoods_xmr:matrix.org> 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.

<s​needlewoods_xmr:matrix.org> But definitely overlooked how the `submit_transfer` does it.

<s​needlewoods_xmr:matrix.org> Just glad I found it while working on something else and it's fixed before it's causing problems

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1236

<s​needlewoods_xmr:matrix.org> Hey

<j​berman:monero.social> *waves*

<r​brunner7:monero.social> Could be that message propagation is slow today?

<r​brunner7:monero.social> Anyway, any reports from last week?

<j​effro256:monero.social> Howdy

<s​needlewoods_xmr:matrix.org> as mentioned earlier "began to remove the MMS, after a chat with tobtoht, with the idea we can re-introduce it post FCMP++"

<s​needlewoods_xmr:matrix.org> and worked on some more multisig related stuff in simplewallet

<s​needlewoods_xmr:matrix.org> and also fixed an issue I created

<s​needlewoods_xmr:matrix.org> idk seems normal to me

<j​effro256:monero.social> 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

<r​brunner7:monero.social> With dediciding among how many submissions?

<r​brunner7:monero.social> *deciding

<j​berman:monero.social> 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

<r​brunner7:monero.social> I would guess 2 or 3 submissions?

<j​berman:monero.social> 5 distinct contestants (including the initial round prior to the deadline extension), and 1 contestant had multiple submissions

<r​brunner7:monero.social> Wow

<j​effro256:monero.social> For the second deadline, there were 4 submitters, with one of them submitting 4 submission variations

<r​brunner7:monero.social> So it became a true contest in the end

<j​effro256:monero.social> And one submitted 2 minutes before the deadline ;)

<r​brunner7:monero.social> Lol

<j​effro256:monero.social> Yes absolutely, which made it pretty hard to judge honestly. Lots of good stuff

<j​effro256:monero.social> *"judge, honestly" ... *not* "judge honestly" lol

<r​brunner7:monero.social> Understood :)

<r​brunner7:monero.social> If that's it about the reports, I have a question, with the people in the know probably attending:

<r​brunner7:monero.social> Somebody made a multisig related CCS proposal: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/595

<r​brunner7:monero.social> As it looks to me, some serious work, for some serious money, 300 XMR

<r​brunner7:monero.social> I wonder where we currently stand with Monero multisig

<r​brunner7:monero.social> SNeedlewoods: You said you had a chat with tobtoht regarding this. Any interesting details?

<r​brunner7:monero.social> Assuming it's ok to share them

<s​needlewoods_xmr:matrix.org> tobtoht: "I've mostly lost interest in finishing it before the FCMP++ fork, given how brittle the current multisig implementation is."

<j​berman:monero.social> 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

<s​needlewoods_xmr:matrix.org> my understanding of our multisig is slowly building up, but I still lack knowledge of many details and the great picture

<r​brunner7:monero.social> Yeah, I know that there is something in the "Serai / Rust universe" of code, but does not know much more than that it exists

<j​effro256:monero.social> 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

<r​brunner7:monero.social> 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.

<t​obtoht:monero.social> The main motivator was getting CCS funds in a multisig wallet to mitigate another hacking incident.

<j​effro256:monero.social> 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++

<j​effro256:monero.social> Or some other bespoke FCMP++ alternative

<r​brunner7:monero.social> Remember that. Do I get it that you did not give up on multisig, but you wait for better preconditions after the FCMP++ hardfork?

<t​obtoht:monero.social> Yes.

<r​brunner7:monero.social> 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?

<j​effro256:monero.social> FROST would be nice for the CCS use-case since the secret shares are publicly verifiable IIRC

<j​effro256:monero.social> But that's incompatible with the multisig wallets in the reference codebase

<r​brunner7:monero.social> Yes, there is the question whether we would have to keep the "old" multisig alive, for compatibility reasons. I tend towards "yes" right now

<j​effro256:monero.social> 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

<j​berman:monero.social> 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

<r​brunner7:monero.social> Interesting. Will the Rust multisig stuff be part of some code review?

<s​needlewoods_xmr:matrix.org> github.com/cypherstack/frostlass

<s​needlewoods_xmr:matrix.org> not sure if this is what we're talking about

<j​berman:monero.social> this audit includes it in scope: ccs.getmonero.org/proposals/monero-serai-wallet-audit.html

<r​brunner7:monero.social> It seems to link to the right repo

<j​berman:monero.social> kayabanerve will probably have commentary / corrects / clarifications on this discussion as well fwiw

<r​brunner7:monero.social> 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

<r​brunner7:monero.social> I also dream there about a multisig workgroup that brings everything on the right tracks, with good project management and broad consensus :)

<r​brunner7:monero.social> 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

<r​brunner7:monero.social> What I would imagine in the proverbial ideal world

<r​brunner7:monero.social> But of course I readily admit that people can build whatever they like, and people can donate for what they like.

<j​effro256:monero.social> 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...

<r​brunner7:monero.social> 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.

<r​brunner7:monero.social> Alright. Maybe comment at the CCS proposal if you feel like it :)

<s​needlewoods_xmr:matrix.org> multisig workgroup sounds important for that

<j​effro256:monero.social> 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

<r​brunner7:monero.social> 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 ...

<r​brunner7:monero.social> At least that was my own reason to stuff everything into the CLI wallet, and *not* making a standalone MMS thing

<j​effro256:monero.social> 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: xkcd.com/927

<r​brunner7:monero.social> I see that we dream along the same lines, jeffro :)

<r​brunner7:monero.social> Our super-strong project management capabilities will save the day. Ahem.

<r​brunner7:monero.social> Alright, nice to see where we stand with multisig. Anything else to discuss today still?

<r​brunner7:monero.social> Does not look like it. Thanks everybody for attending, read you again next week!

<s​needlewoods_xmr:matrix.org> thank you

<k​ayabanerve:matrix.org> 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