02:15:54 <m-relay> <k​ayabanerve:matrix.org> I published the Rust documentation for monero-wallet to GH pages: https://docs.serai.exchange/rust/monero_wallet. cc rbrunner who wanted to better understand what monero-serai/monero-wallet is (monero-wallet re-exports all of monero-serai so the ringct/transaction/block/etc modules in monero-wallet are from monero-serai).
02:15:55 <m-relay> <k​ayabanerve:matrix.org> These would be available @ https://docs.rs/monero-wallet if these were published crates. I'm waiting to publish the 1.0 until after the audits occur.
02:15:57 <m-relay> <k​ayabanerve:matrix.org> I've also written a gist overviewing the potential of using monero-clsag/monero-wallet with wallet2 for the purposes of multisig: https://gist.github.com/kayabaNerve/3b2c648c623bc4ce4ca288725428ea76 It isn't as seamless as I'd want it to be, yet given _it wasn't a use-case I considered before the MRL meeting and is something I've written 0 code for_, I think it's fine. The code wa<clipped message
02:15:59 <m-relay> <k​ayabanerve:matrix.org> s done with enough flexibility and a robust enough API it is possible. cc tobtoht
02:16:01 <m-relay> <k​ayabanerve:matrix.org> I'd like to discuss this again at the next MRL meeting (cc Rucknium). I'd also like to bring up the context for this again. monero-serai/monero-wallet were developed over years to fulfill a suitable multisig and a proper Rust way to work with Monero. It isn't being proposed to replace cryptonote-core nor monerod nor wallet2. It is a library which is part of the ecosystem. As of ri<clipped message
02:16:03 <m-relay> <k​ayabanerve:matrix.org> ght now, even ignoring any work on Seraphis, there's at least two wallet libraries with active CCSs and two wallets with active CCSs. This proposal is a drafted CCS which would sit next to those CCSs. AFAIK, those CCSs had no discussion in MRL and I only raised it here as plowsof said audits get kicked here. While I do welcome discussion over my proposal (I truly don't want to ign<clipped message
02:16:05 <m-relay> <k​ayabanerve:matrix.org> ore anyone's criticism/commentary), I do think the reminder that I'm proposing auditing a library in the ecosystem, not funding R&D on yet another next-gen protocol that Monero will be expected to adopt, is good to have.
02:21:30 <m-relay> <k​ayabanerve:matrix.org> I'll also cc Rucknium on the note if asked if I was funded for Serai, my answer would be "Serai received no funding yet the monero-community funded the audits for the public-good Monero libraries we built." I wouldn't censor the role of the CCS (which my saying "NACK" to your message could be misinterpreted as). I just still wouldn't say Serai was funded by the CCS as I don't actu<clipped message
02:21:31 <m-relay> <k​ayabanerve:matrix.org> ally receive money from this. It's one less expense I would've otherwise burdened when I was reasonably able to (which I unfortunately am not at this time). I do get how that's a gray line but since I/the project has never directly received funding, none of this code is Serai specific, it's a touchy subject for me for a few reasons, and I do want to keep Serai considered independe<clipped message
02:21:33 <m-relay> <k​ayabanerve:matrix.org> nt, it's a line I'm sticking to.
02:48:39 <m-relay> <k​ayabanerve:matrix.org> Eh. I'm not proposing another next-gen protocol. I am proposing academic formalization of a multisig protocol for CLSAG. Said multisig protocol is the one I implemented, not the one in wallet2. I do have to fully ack that and sufficiently justify why monero-clsag's multisig beats wallet2's multisig. While I think I've done that via arguing the complexity (O(n!) -> O(n)) / academic<clipped message
02:48:41 <m-relay> <k​ayabanerve:matrix.org>  basis (FROST) / functionality (identifiable aborts, modular to the DKG protocol), it does deserve proper discussion.
02:48:43 <m-relay> <k​ayabanerve:matrix.org> Its also important to note wallet2's actual signing protocol is effectively Musig2 and also should be largely fine. The signing process only has the horrible complexity it does because of the DKG having O(n!) complexity and outputting O(n!) shares (which then get used in an O(n) signing protocol, where `n` is the amount of shares output from the DKG). Sane DKGs have O(n**2) comple<clipped message
02:48:45 <m-relay> <k​ayabanerve:matrix.org> xity and output n shares. That's inevitable so long as wallet2 wants to offer threshold multisigs _and_ use a non-threshold signing protocol, yet updating the signing protocol to be threshold (like FROST) wouldn't be months of work. It's the DKG which would take a notable amount of time to change.