01:54:13 There's also all my prior notes, which respond to the other inaccuracies, for anyone solely joining the conversation now. 01:57:59 I do understand comparing the e2e experiences, and that's why we can factor the DKG into the discussion, but then the FROST has four DKGs: 01:57:59 - PedPoP, 2 rounds + 1 round to confirm the key or abort, written as a n-of-n implementation, sharing a t-of-n key 01:58:00 - MuSig (non-interactive, n-of-n key) 01:58:00 - Dealer (trusted setup) 01:58:00 - eVRF, either 1-round t-of-n with agreement on the subset of participants, or n-of-n with everyone participating, sharing a t-of-n key 01:59:55 Serai designed, implemented, contracted security proofs for*, audited, and will use the eVRF DKG. 01:59:55 *the security proofs for the novel encryption scheme have not received any challenge. The security proofs for its composition into a traditional DKG did receive criticism. I'm not concerned as it's a bog-standard DKG. 02:00:10 *the relevant FROST implementation has four DKGs 02:02:04 The PedPoP DKG, which I extended with identifiable aborts in a manner effectively equivalent to ICE FROST, has an implementation I wrote and it was audited by Cypher Stack. It also has some known bugs (reachable panics) and is no longer being maintained under Serai. 02:02:34 The MuSig impl is maintained under Serai, and I believe was included in the audit by CS? I'd have to check. 02:02:50 The dealer impl is maintained under Serai, but more as a test utility/just to have it. 02:03:16 I plan to personally maintain the pedpop library but honestly haven't bothered at this time, it's super low priority for me. 02:17:56 Thanks for the information. It seems Dealer and MuSig (with FROST) would be a bit of a regression 02:21:40 Based on what I can tell from a quick glance (however inaccurate that may be), it seems PedPoP is a bit more conservative and reputable 02:24:06 Do you have a reason for this, other than convenience? I'm (obviously) not some sort of authority on this, but outsourcing more critical logic to code we don't control, among other downsides, doesn't sit well with me. A few others have also surfaced this concern > <@kayabanerve:matrix.org> If wallet2 is to include multisig, it should be via the Rust libs moving forward IMO. 02:41:45 Using this Rust code already multiplies the trust surface by, like, an order of magnitude 02:48:41 The current 'legacy' code implementation appears to be ~7,400 lines of code, and from what I can tell based off of other implementations/current code, implementing FROST (plus the DKG) in C/C++ would take maybe a 4,000-line diff, not counting tests 02:51:21 Due to all of the stuff with bindings, the only differences I see are basically the same size of diff, coupled with worse supply-chain security 03:03:25 @jpk68:matrix.org: If you pick one and only one. MuSig makes sense where it can be used. Serai uses it to form n-of-n without additional communication. 03:04:14 Whereas for the (party, arbiter, party)-case, the eVRF may make sense as one party and the arbiter can do a keygen _and ensure the third party has their key, even if they're offline_ 03:04:46 But in general, PedPoP is a decent all around choice, if you fan successfully manage it 03:05:04 Monero does control the Rust code, so that's a poor argument. The fact it's hosted in a third-party repo doesn't change it's hash-pinned AFAIK. 03:05:16 Multisig is a massive scope and we're already simply using the Rust for FCMP++ afaik 03:05:24 Why would we bother maintaining the C++ monstrosity 03:05:32 Kick it out, if you want to maintain it, feel free to 03:05:50 But then the Q is if we should kick multisig out entirely or transition to the Rust that's right there with the FCMP++ libs 03:06:11 Literally, the FCMP++ lib we use for verifying signatures also contains the multisig algorithms for them 03:06:42 So you're adding 4k lines for no reason, and then encountering the review, audit, maintenance burden already being paid by the Rust 03:06:59 In that case, why do you care that much what happens with C++ consensus logic? > <@kayabanerve:matrix.org> Why would we bother maintaining the C++ monstrosity 03:07:07 Again, the C++ impl would solely be additive (as of FCMP++) because the multisig algorithms are in the same lib as the cefifier we're already shipping 03:07:13 *verifier 03:07:28 > Kick it out, if you want to maintain it, feel free to 03:07:31 @jpk68:matrix.org: 03:07:35 I already commented to that 03:07:52 That doesn't change that as of FCMP++, a continued C++ impl in Monero proper will be absurd. 03:08:05 Going from 8-9 vendored/submoduled C/C++ dependencies to 70-80 Rust crates is an insane increase in supply-chain attack surface, end of story. 03:08:32 All of cuprate, including the full rust crate dep tree, is smaller than boost alone 03:08:45 And again, that's happening with FCMP++. Suck it up or fork off. I'm tired of this discussion. 03:08:52 Maybe if you look at it from that one-dimensional angle 03:09:12 Once FCMP++ happens, a C++ impl in the codebase will solely be a massive burden that's solely duplicated effort. 03:09:32 4k lines of C++, plus cryptographic review and auditing 03:09:32 Or 100 lines of FFI bindings to the libs we're already shipping 03:10:06 But the burden of trying to get people to run Guix builds, especially after adding another entire toolchain, plus duplicating attack surface, we don't care about that, apparently 03:10:28 I'll support there being a C++ impl. I just don't support it as Monero's burden. 03:10:40 Dude, this discussion was settled two years ago and you're just a troll now. 03:11:04 Unless you actually want to halt the HF, please just shut the fuck up, at least around me ffs 03:11:16 Or do your own C++ impl, audit it, and PR that instead 03:11:21 I have a legitimate concern that you disagree with, it's nothing personal 03:11:41 You're not calling to do better though 03:11:51 You're just bashing on Rust in a way which suggests we should halt the HF 03:12:19 I'm not suggesting that. I think I was added as a co-author to the PR adding the Rust toolchain, actually 03:12:35 Your concerns are a waste of time as they have zero productive focus, and here suggest Monero should have the burden of re-impl'ing and maintaining a massive subsystem, we already have via the Rust libs we're already shipping 03:12:59 If you're not calling to halt the HF, and you're not ready with a full C++ alt, than fucking accept we have Rust libs as of the hard fork 03:13:32 Stop bringing up the 'Guix challenge', which is present either way, and suggesting a Rust multisig an increase in scope 03:13:37 It's the C++ rewrite that is 03:13:57 It's nice that it's finally being made clear how little some people care about this stuff. Apparently the concerns I have, that others also share, are just 'invalid' and I'm a troll for disagreeing 03:14:06 I have never once suggested delaying the HF, by the way 03:14:29 I'm not sure what motivation I would have for this. Why would I waste my time arguing about this if I didn't care about it? 03:16:58 I don't want to have a personal issue with you and I'll apologize for lashing out, but I have to be clear 03:16:59 This discussion happened two years ago 03:17:00 It was settled two years ago 03:17:01 You can have concerns now 03:17:02 Trolling about those concerns is still trolling 03:17:35 If you accept the HF is happening, and aren't suggesting otherwise, then get on the same page 03:17:44 How is it trolling? It's raising a concern 03:17:44 I don't know how much more clear I can be - I don't propose delaying anything. My point is that we shouldn't keep using third-party consensus code in the long run 03:17:57 I'll be happy to discuss how to do better in the future, but you're not presenting that discussion IMO, and we have a communication breakdown 03:18:25 My point is that I disagree with having Rust code in the main repo forever. Is that hard to understand? 03:18:29 One of your arguments is that adding Rust is a massive increase in scope. that's unfair and what I'm calling out. 03:18:46 We've already decided to add Rust. You can't now bitch ad infinitum about adding Rust. 03:19:02 You can say, we can exchange this massive set of deps for solely C++. I understand and maybe even support that. 03:19:05 You don't have to repeatedly curse at me, thanks 03:19:19 It isn't adding Rust vs adding C++ though. 03:19:25 It's replacing the added Rust with C++. 03:20:06 You don't have to concern troll all the time in a way which, from my interactions with you, makes me think your primary existence in the community is to bash Rust and FUD the HF under the guise of supply chain security. 03:20:42 I'm tired of it and I'm done sitting by in conversations I'm going to be part of. We either have to resolve how to communicate or I'll just leave, fuck this shit. 03:20:56 > primary existence in the community 03:20:56 > Thanks for ignoring all the other stuff I'm doing :) 03:21:04 Now, I hear if we are miscommunicating and I'm sorry on my end for my part in that. 03:21:13 Again, not sure what part of my argument makes you think I'm "trolling" 03:21:13 > makes me think your primary existence 03:21:40 Dude, from my perspective, this is effectively all you do, and that's my point about why it comes off as trolling. 03:21:47 > Going from 8-9 vendored/submoduled C/C++ dependencies to 70-80 Rust crates is an insane increase in supply-chain attack surface, end of story. 03:22:06 You said this ~15 minutes ago. that is happening with the FCMP++ hard fork. End of story. 03:22:23 You can't infinitely relitigate that be and claim it to be fair and honest debate. 03:22:36 You have repeatedly told me in this convo to "shut the fuck up" and are saying I'm "bitching" and "concern trolling" 03:22:36 How's that for an invalid argument? 03:22:46 How does that make a fair and honest debate? 03:22:51 Isn't that literally ad hominem? 03:23:13 Do you want to try and work past this miscommunication or should we just ignore each other moving forward? 03:23:25 Or at least, should I do my best to ignore you? 03:23:35 I think it would be a bit ridiculous to say I don't do anything besides complaining about Rust. Come on, I work on some stuff 03:23:55 @kayabanerve:matrix.org: I think you're going to keep dismissing my concerns as invalid either way, so I'm not sure what difference it makes 03:24:30 "makes me think your primary existence" 03:24:30 "Dude, from my perspective, this is effectively all you do, and that's my point about why it comes off as trolling." 03:24:30 I feel my messages were fair. 03:24:35 I've tried to acknowledge it though. 03:24:47 > You can say, we can exchange this massive set of deps for solely C++. I understand and maybe even support that. 03:24:59 > I'll be happy to discuss how to do better in the future, but you're not presenting that discussion IMO, and we have a communication breakdown 03:25:21 Thank you for interleaving your swearing with some pleasantaries 03:25:21 I've been trying to reframe this in a positive way, despite the negativity I've thrown in 03:26:25 So when is the elusive hard fork :P 03:26:27 But a discussion on the future of Monero can't start with the downsides of adding Rust, as we've already decided on that. It has to be the discussion on what that looks like in the future, and potentially replacing it, which isn't the discussion you present AFAICT. 03:27:22 If its 3yrs away, we probably have time for a reimpl 🥹 03:28:10 * crates.io is a centralized point of failure, and depends on GitHub, which is owned by Microsoft 03:28:10 * Rust code narrows the scope of who can review the code, because not all Monero contributors can program in Rust 03:28:10 * The scope of a live dependency tree never comes close to the level of review for actual Monero PRs 03:28:10 * Adding a second toolchain is not a one-time integration cost 03:28:10 * Guix reproducibility is not just a preference, it's a structural mismatch (yes, I know I used an "it's not just X, it's Y" sentence) 03:28:12 Do you want to continue with discussing my usage of the English language for emphasis, or would you also like to work on better communicating in the future with me? It's clear we have distinct frames entering this discussion, my issue being I'm fucking exhausted with this conflict and won't tolerate it anymore. We can either r [... too long, see https://mrelay.p2pool.observer/e/r5eFjqsLelphMEJR ] 03:28:47 Yeah, see, now it feels like we're re-litigating what we've already decided two years ago and you're just concern trolling. 03:28:59 I'm not trying to play 5D space chess here. I'm just expressing my concern, it's nothing about you, please don't take it seriously 03:29:12 I have no ulterior motives, I literally just dislike the idea of adding Rust 03:29:12 You're bashing Rust without any actual discussion on alternatives or doing better in the future, nor open questions to have a conversation with. 03:29:37 K, so do you want to halt the HF, do you just want to bitch, do you want to work together, or do you want to shut the fuck up? 03:29:52 Because those are your four options AFAICT, and for the past month, I've just seen you bitching 03:30:07 I'd rather we work together OR you shut the fuck up 03:30:10 @kayabanerve:matrix.org: Not sure if you're reading my messages. I think I said I didn't want to halt it, actually 03:30:30 Yes, but when you then keep saying why it's a bad idea, you fail to communicate that 03:30:38 "Oh, no, I don't want anything for my birthday" 03:30:55 "Oh, no, I don't want to halt the hard fork. I just think it's a horrible idea. I just care about Monero" 03:30:58 At this point, you're just cursing at me for no reason, and I don't appreciate it > <@kayabanerve:matrix.org> K, so do you want to halt the HF, do you just want to bitch, do you want to work together, or do you want to shut the fuck up? 03:31:01 This is how your messages come across to me. 03:31:52 The guy who keeps telling me to "shut the fuck up" seems to dislike how my messages are coming across? Ironic 03:31:53 And I keep trying to repivot into productive conversation and you keep remaining with your bitching and your ad hominem issues, so I'll take it you don't want to work together, and do just in fact want to bitch 03:32:13 I think you can try and cool down :) 03:32:31 Have fun with that. Sorry to the room for blowing up publicly but this is exhausting and just never ends. It started as a legitimate discussion on multisig and just devolved into this garbage. 03:33:12 I wonder which one of us has had smoke pouring out of our ears this entire "discussion" 03:35:10 What? > <@kayabanerve:matrix.org> "Oh, no, I don't want anything for my birthday" 03:35:33 Just an example of ad hominem, i think 03:35:43 Shh, nno talking during the movie 05:57:16 We had a nice chat about Monero multisig in Monday's tech meeting, there was now a not-so-nice chat about Monero multisig and other things in the last few hours. 05:58:06 As I see it, that was it with chats. To move things forward in a productive way, something else is needed now. Merely chatting is the wrong format. 05:59:47 I propose that @jpk68:matrix.org works out a detailed and well-explained plan what they proprose about Monero multisig: What shall get changed in the code, or newly built in the code, with what goals? And then opens a GitHub issue for publishing that plan. 06:01:21 If that's not possible, say because working out that plan is too complex for them, or because they themselves lack time to do it, step back one level and work out a plan how to develop that plan, and publish that 06:02:06 Brutally simplified, two things can happen, either with the plan, or the plan how to arrive at that plan: 06:03:08 The issue gets broad enough support, and we can start the next phase of manpower search "Who codes that?" and maybe "How we finance that?". 06:03:34 Or, alternatively, support does not materialize, and then that's the end of the line. 12:24:47 Sounds good to me.