remind me on Sunday to upgrade this room (and probably a couple of others) to the new bridge, should be a bit easier to handle the conversations with the upcoming beta

<k​ayabanerve:matrix.org> It doesn't. There's libraries for PedPoP, MuSig, a publicly-verifiable variant of the eVRF DKG, and also a dealer key gen.

<k​ayabanerve:matrix.org> Monero's can be interpreted as a n-of-n key generation like MuSig. The lack of verification shares will break identifiable aborts, but everything else should be fine.

<k​oe000:matrix.org> I'm talking about this github.com/monero-oxide/monero-oxid…mp%2B%2B/src/sal/legacy_multisig.rs

<k​ayabanerve:matrix.org> koe000: So am I?

<k​ayabanerve:matrix.org> modular_frost::ThresholdKeys is a re-export of dkg::ThresholdKeys

<k​ayabanerve:matrix.org> It isn't FROST-specific

<k​ayabanerve:matrix.org> It isn't directly totally applicable, as it expects verification shares, but I can attest you can just randomly set those for GIGO behavior.

<k​ayabanerve:matrix.org> (please test to confirm that behavior, as that should be the case but no, I didn't myself test these libraries still work to a desired subset of functionality when you use garbage data for what should be a distinct subset)

<k​oe000:matrix.org> I see, I will look at it deeper then.

<k​ayabanerve:matrix.org> modular-frost itself is just a framework for two-round signing protocols for linear signature schemes, with binomial nonces in the first round.

<k​ayabanerve:matrix.org> dkg handles the secret sharing and interpolation and can be used with n-of-n schemes.

<k​oe000:matrix.org> Ok did better research, the rust impl makes sense. The `R_alpha` double-use I'm not 100% on yet but otherwise it matches my expectations.