09:26:52 <m-relay> <a​nddn:matrix.org> The Tor network is being rewritten in Rust. Should Monero also consider rewriting it in Rust? Because C++ is too cumbersome and not suitable for the long-term development of Monero.🤔
09:34:26 <sech1> Oh no, not this again 🙄
09:36:09 <sech1> Rust is a language that's too overhyped for what it can really achieve, plus it suffers from the supply chain plague https://redteamnews.com/threat-intelligence/supply-chain-attack-targets-rust-developers-through-malicious-crates/
09:36:14 <sech1> Good choice for Monero? I say no
09:37:31 <sech1> The C++ official repo will stay there for the foreseeable future and be the main source of the official binaries. But there is Cuprate project, if you're interested
09:48:50 <m-relay> <k​ayabanerve:matrix.org> Tor and Monero both have alternative implementations in Rust under development. I don't believe Tor is deprecating their C and Monero definitely isn't.
09:50:49 <m-relay> <k​ayabanerve:matrix.org> > We intend that, in the long run, Arti will replace our C tor implementation completely, not only for clients, but also for relays and directory authorities. This will take several more years of work, but we're confident that it's the right direction forward.
09:50:49 <m-relay> <k​ayabanerve:matrix.org> >
09:50:51 <m-relay> <k​ayabanerve:matrix.org> > (We won't stop support for the C implementation right away; we expect that it will take some time for people to migrate.)
09:50:53 <m-relay> <k​ayabanerve:matrix.org> TIL
09:51:56 <m-relay> <k​ayabanerve:matrix.org> Monero also is adopting Rust dependencies with FCMP++ and I personally find it incredibly appropriate.
09:52:50 <m-relay> <k​ayabanerve:matrix.org> (sech1 is welcome to rewrite FCMP++ in C++ and have Cuprate adopt C++ dependencies though ;) )
09:53:26 <sech1> I would rather rewrite it in C with some ASM code for max performance
09:53:33 <sech1> If it comes to rewrite
09:53:49 <sech1> Also, C is much easier to bring to other languages
09:54:26 <sech1> How many lines of code is FCMP++ currently?
09:54:34 <m-relay> <k​ayabanerve:matrix.org> Rust can expose a C FFI FWIW
09:54:54 <m-relay> <k​ayabanerve:matrix.org> 10-20k, not counting deps?
09:55:24 <m-relay> <k​ayabanerve:matrix.org> I can check in a few
09:55:41 <sech1> A full rewrite is an overkill then
09:55:46 <sech1> but some performance critical parts - why not
09:57:01 <m-relay> <k​ayabanerve:matrix.org> Tbh I'd love a second verifier implementation
09:57:40 <m-relay> <k​ayabanerve:matrix.org> You also can probably get it much more concise if you remove the prover and strip 'unnecessary' functionality
09:59:00 <sech1> If if can be rewritten in parts and interconnect with Rust code with C FFI, I can do it gradually
09:59:21 <sech1> maybe even make a CCS proposal for it
09:59:25 <sech1> because it will be a lot of work
10:00:05 <sech1> 10-20k lines of code is at least 3-4 weeks of full time work to get an MVP
10:00:18 <sech1> minimal viable product
10:01:19 <m-relay> <k​ayabanerve:matrix.org> I didn't implement the FCMP. I implemented a framework for proofs over Bulletproof, composable parts for such proofs, and then the FCMP on top, as necessary to satisfy review and ensure we could actively develop it.
10:01:36 <m-relay> <k​ayabanerve:matrix.org> You can probably cut a lot of that out and bake in the FCMP specifically though.
10:02:35 <m-relay> <k​ayabanerve:matrix.org> It won't be explanatory and may be hell to audit, but it doesn't have to be audited to be correct. Solely corresponding.
10:04:13 <m-relay> <k​ayabanerve:matrix.org> https://github.com/monero-oxide/monero-oxide/pull/29 14k lines, excluding deps, a month ago
10:06:02 <sech1> Second implementation can be really helpful to find new issues - P2Pool got a lot bug reports and some vulnerabilities fixed when DataHoarder was writing the P2Pool Observer
10:07:00 <m-relay> <k​ayabanerve:matrix.org> The external deps are likely just blake2, ed25519 if you want to be minimal however.
10:11:58 <sech1> blake2 and ed25519 already have good C implementations, perfect
10:17:39 <DataHoarder> A key part of that was also running the same tests but with different code too (found shuffle stuff) or easier time fuzzing
10:27:17 <DataHoarder> Not be a 1:1 implementation but try to make it specific to the language, then test very well the consensus parts
11:35:51 <DataHoarder> not making a PR for this yet https://github.com/WeebDataHoarder/monero/commit/755bf842023c6b52881934e4a6b02d265f70e7ce
11:35:51 <DataHoarder> This fixes a long term bug where signing messages from Monero GUI watch-only wallet produces a signed message ... signed from the spend key, using the valid spend pub, but using the "zero" private key
11:36:07 <DataHoarder> (also allows view key signatures to happen on watch-only mode when specified)
11:36:37 <DataHoarder> on the main address, at least
11:36:53 <DataHoarder> sign 0,0 --view proof.txt
11:36:53 <DataHoarder> Error: wallet is watch-only and cannot sign
11:36:53 <DataHoarder> ^ this would work
11:38:17 <DataHoarder> to repro the issue on Monero GUI do this, on a watch-only wallet: Go Advanced->Sign/verify, Sign Message (sign anything here), ... scroll below and verify it again :)
11:40:41 <DataHoarder> I had the specific detection from two years ago more or less where checking a signature against spend/view pub commitment, but the signature was generated using the zero private key https://git.gammaspectra.live/P2Pool/consensus/src/branch/master/monero/address/crypto.go#L151-L154
14:10:14 <selsta> .merge+ 10115 10114 10113 10112 10110 10104 10103 10098 10097 9939 9901 
14:10:14 <xmr-pr> Added