<kayabanerve:matrix.org> There's also all my prior notes, which respond to the other inaccuracies, for anyone solely joining the conversation now.

<kayabanerve:matrix.org> 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:

<kayabanerve:matrix.org> - PedPoP, 2 rounds + 1 round to confirm the key or abort, written as a n-of-n implementation, sharing a t-of-n key

<kayabanerve:matrix.org> - MuSig (non-interactive, n-of-n key)

<kayabanerve:matrix.org> - Dealer (trusted setup)

<kayabanerve:matrix.org> - 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

<kayabanerve:matrix.org> Serai designed, implemented, contracted security proofs for*, audited, and will use the eVRF DKG.

<kayabanerve:matrix.org> *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.

<kayabanerve:matrix.org> *the relevant FROST implementation has four DKGs

<kayabanerve:matrix.org> 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.

<kayabanerve:matrix.org> The MuSig impl is maintained under Serai, and I believe was included in the audit by CS? I'd have to check.

<kayabanerve:matrix.org> The dealer impl is maintained under Serai, but more as a test utility/just to have it.

<kayabanerve:matrix.org> I plan to personally maintain the pedpop library but honestly haven't bothered at this time, it's super low priority for me.

<jpk68:matrix.org> Thanks for the information. It seems Dealer and MuSig (with FROST) would be a bit of a regression

<jpk68:matrix.org> 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

<jpk68:matrix.org> 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.

<jpk68:matrix.org> Using this Rust code already multiplies the trust surface by, like, an order of magnitude

<jpk68:matrix.org> 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

<jpk68:matrix.org> 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

<kayabanerve:matrix.org> @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.

<kayabanerve:matrix.org> 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_

<kayabanerve:matrix.org> But in general, PedPoP is a decent all around choice, if you fan successfully manage it

<kayabanerve:matrix.org> 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.

<kayabanerve:matrix.org> Multisig is a massive scope and we're already simply using the Rust for FCMP++ afaik

<kayabanerve:matrix.org> Why would we bother maintaining the C++ monstrosity

<kayabanerve:matrix.org> Kick it out, if you want to maintain it, feel free to

<kayabanerve:matrix.org> 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

<kayabanerve:matrix.org> Literally, the FCMP++ lib we use for verifying signatures also contains the multisig algorithms for them

<kayabanerve:matrix.org> So you're adding 4k lines for no reason, and then encountering the review, audit, maintenance burden already being paid by the Rust

<jpk68:matrix.org> 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

<kayabanerve:matrix.org> 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

<kayabanerve:matrix.org> *verifier

<kayabanerve:matrix.org> > Kick it out, if you want to maintain it, feel free to

<kayabanerve:matrix.org> @jpk68:matrix.org:

<kayabanerve:matrix.org> I already commented to that

<kayabanerve:matrix.org> That doesn't change that as of FCMP++, a continued C++ impl in Monero proper will be absurd.

<jpk68:matrix.org> 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.

<kayabanerve:matrix.org> All of cuprate, including the full rust crate dep tree, is smaller than boost alone

<kayabanerve:matrix.org> And again, that's happening with FCMP++. Suck it up or fork off. I'm tired of this discussion.

<jpk68:matrix.org> Maybe if you look at it from that one-dimensional angle

<kayabanerve:matrix.org> Once FCMP++ happens, a C++ impl in the codebase will solely be a massive burden that's solely duplicated effort.

<kayabanerve:matrix.org> 4k lines of C++, plus cryptographic review and auditing

<kayabanerve:matrix.org> Or 100 lines of FFI bindings to the libs we're already shipping

<jpk68:matrix.org> 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

<kayabanerve:matrix.org> I'll support there being a C++ impl. I just don't support it as Monero's burden.

<kayabanerve:matrix.org> Dude, this discussion was settled two years ago and you're just a troll now.

<kayabanerve:matrix.org> Unless you actually want to halt the HF, please just shut the fuck up, at least around me ffs

<kayabanerve:matrix.org> Or do your own C++ impl, audit it, and PR that instead

<jpk68:matrix.org> I have a legitimate concern that you disagree with, it's nothing personal

<kayabanerve:matrix.org> You're not calling to do better though

<kayabanerve:matrix.org> You're just bashing on Rust in a way which suggests we should halt the HF

<jpk68:matrix.org> I'm not suggesting that. I think I was added as a co-author to the PR adding the Rust toolchain, actually

<kayabanerve:matrix.org> 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

<kayabanerve:matrix.org> 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

<kayabanerve:matrix.org> Stop bringing up the 'Guix challenge', which is present either way, and suggesting a Rust multisig an increase in scope

<kayabanerve:matrix.org> It's the C++ rewrite that is

<jpk68:matrix.org> 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

<jpk68:matrix.org> I have never once suggested delaying the HF, by the way

<jpk68:matrix.org> 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?

<kayabanerve:matrix.org> I don't want to have a personal issue with you and I'll apologize for lashing out, but I have to be clear

<kayabanerve:matrix.org> This discussion happened two years ago

<kayabanerve:matrix.org> It was settled two years ago

<kayabanerve:matrix.org> You can have concerns now

<kayabanerve:matrix.org> Trolling about those concerns is still trolling

<kayabanerve:matrix.org> If you accept the HF is happening, and aren't suggesting otherwise, then get on the same page

<jpk68:matrix.org> How is it trolling? It's raising a concern

<jpk68:matrix.org> 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

<kayabanerve:matrix.org> 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

<jpk68:matrix.org> My point is that I disagree with having Rust code in the main repo forever. Is that hard to understand?

<kayabanerve:matrix.org> One of your arguments is that adding Rust is a massive increase in scope. that's unfair and what I'm calling out.

<kayabanerve:matrix.org> We've already decided to add Rust. You can't now bitch ad infinitum about adding Rust.

<kayabanerve:matrix.org> You can say, we can exchange this massive set of deps for solely C++. I understand and maybe even support that.

<jpk68:matrix.org> You don't have to repeatedly curse at me, thanks

<kayabanerve:matrix.org> It isn't adding Rust vs adding C++ though.

<kayabanerve:matrix.org> It's replacing the added Rust with C++.

<kayabanerve:matrix.org> 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.

<kayabanerve:matrix.org> 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.

<jpk68:matrix.org> > primary existence in the community

<jpk68:matrix.org> > Thanks for ignoring all the other stuff I'm doing :)

<kayabanerve:matrix.org> Now, I hear if we are miscommunicating and I'm sorry on my end for my part in that.

<jpk68:matrix.org> Again, not sure what part of my argument makes you think I'm "trolling"

<kayabanerve:matrix.org> > makes me think your primary existence

<kayabanerve:matrix.org> Dude, from my perspective, this is effectively all you do, and that's my point about why it comes off as trolling.

<kayabanerve:matrix.org> > 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.

<kayabanerve:matrix.org> You said this ~15 minutes ago. that is happening with the FCMP++ hard fork. End of story.

<kayabanerve:matrix.org> You can't infinitely relitigate that be and claim it to be fair and honest debate.

<jpk68:matrix.org> You have repeatedly told me in this convo to "shut the fuck up" and are saying I'm "bitching" and "concern trolling"

<jpk68:matrix.org> How's that for an invalid argument?

<jpk68:matrix.org> How does that make a fair and honest debate?

<kayabanerve:matrix.org> Isn't that literally ad hominem?

<kayabanerve:matrix.org> Do you want to try and work past this miscommunication or should we just ignore each other moving forward?

<kayabanerve:matrix.org> Or at least, should I do my best to ignore you?

<jpk68:matrix.org> 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

<jpk68:matrix.org> @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

<kayabanerve:matrix.org> "makes me think your primary existence"

<kayabanerve:matrix.org> "Dude, from my perspective, this is effectively all you do, and that's my point about why it comes off as trolling."

<kayabanerve:matrix.org> I feel my messages were fair.

<kayabanerve:matrix.org> I've tried to acknowledge it though.

<kayabanerve:matrix.org> > You can say, we can exchange this massive set of deps for solely C++. I understand and maybe even support that.

<kayabanerve:matrix.org> > 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

<jpk68:matrix.org> Thank you for interleaving your swearing with some pleasantaries

<kayabanerve:matrix.org> I've been trying to reframe this in a positive way, despite the negativity I've thrown in

<ofrnxmr> So when is the elusive hard fork :P

<kayabanerve:matrix.org> 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.

<ofrnxmr> If its 3yrs away, we probably have time for a reimpl 🥹

<jpk68:matrix.org> * crates.io is a centralized point of failure, and depends on GitHub, which is owned by Microsoft

<jpk68:matrix.org> * Rust code narrows the scope of who can review the code, because not all Monero contributors can program in Rust

<jpk68:matrix.org> * The scope of a live dependency tree never comes close to the level of review for actual Monero PRs

<jpk68:matrix.org> * Adding a second toolchain is not a one-time integration cost

<jpk68:matrix.org> * 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)

<kayabanerve:matrix.org> 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 mrelay.p2pool.observer/e/r5eFjqsLelphMEJR ]

<kayabanerve:matrix.org> Yeah, see, now it feels like we're re-litigating what we've already decided two years ago and you're just concern trolling.

<jpk68:matrix.org> 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

<jpk68:matrix.org> I have no ulterior motives, I literally just dislike the idea of adding Rust

<kayabanerve:matrix.org> You're bashing Rust without any actual discussion on alternatives or doing better in the future, nor open questions to have a conversation with.

<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?

<kayabanerve:matrix.org> Because those are your four options AFAICT, and for the past month, I've just seen you bitching

<kayabanerve:matrix.org> I'd rather we work together OR you shut the fuck up

<jpk68:matrix.org> @kayabanerve:matrix.org: Not sure if you're reading my messages. I think I said I didn't want to halt it, actually

<kayabanerve:matrix.org> Yes, but when you then keep saying why it's a bad idea, you fail to communicate that

<kayabanerve:matrix.org> "Oh, no, I don't want anything for my birthday"

<kayabanerve:matrix.org> "Oh, no, I don't want to halt the hard fork. I just think it's a horrible idea. I just care about Monero"

<jpk68:matrix.org> 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?

<kayabanerve:matrix.org> This is how your messages come across to me.

<jpk68:matrix.org> The guy who keeps telling me to "shut the fuck up" seems to dislike how my messages are coming across? Ironic

<kayabanerve:matrix.org> 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

<jpk68:matrix.org> I think you can try and cool down :)

<kayabanerve:matrix.org> 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.

<jpk68:matrix.org> I wonder which one of us has had smoke pouring out of our ears this entire "discussion"

<jpk68:matrix.org> What? > <@kayabanerve:matrix.org> "Oh, no, I don't want anything for my birthday"

<ofrnxmr> Just an example of ad hominem, i think

<ofrnxmr> Shh, nno talking during the movie

<rbrunner7> 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.

<rbrunner7> 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.

<rbrunner7> 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.

<rbrunner7> 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

<rbrunner7> Brutally simplified, two things can happen, either with the plan, or the plan how to arrive at that plan:

<rbrunner7> 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?".

<rbrunner7> Or, alternatively, support does not materialize, and then that's the end of the line.

<jpk68:matrix.org> Sounds good to me.