Participate in FROST Implementers Workshop September 18th?

[ChristopherA]

We are hosting our send FROST library implementors workshop on September 18th https://developer.blockchaincommons.com/frost/meeting2/

So far scheduled are some discussion from bitcoin devs on their FROST implementations in C++. One of the critical issues to me are the issues of x-only pubkey compatibility and the tweaked signatures for use on-chain. All of Blockchain Common's own code base has been moving from C++ to Rust and we'd prefer a rust implementation.

Could we get someone from this team to participate, or even present a brief status update / roadmap your FROST support? Contact me at ChristopherA@LifeWithAlacrity.com if you are interested.

Thanks!

[kayabaNerve]

I reached out on Twitter where we've prior communicated. As a summary for the work present here,

1) We have a DKG library in Rust (with the dkg crate name even) which offers a PedPoP-based biased DKG. We also have an eVRF-based biased PVSS which is robust (only needingt participants, yet achieving a t-of-n multisig with no concern of if a participant has invalid shares). That only requires agreement on a setup, context string, and the first t participants. It can be made non-biased by requiring all n participate (which also means you only need a setup and context string to be agreed upon, not any order of participations). The details can be found in #576.

2) modular-frost is an audited Rust implementation of all FROST ciphersuites, modular to the ciphersuite (curve/HRAM) or even the signing protocol. I've personally adapted the idea of FROST to Monero's CLSAG (a distinct proof which is amenable to the same techniques). I've also made a ciphersuite for Ethereum (using an HRAM efficiently verifiable in the EVM). For Bitcoin, we wrap the provided Schnorr signing protocol (with the Bitcoin HRAM) into a Bitcoin signing protocol which achieves the necessary commentary on parity. You can see what that looks like here: https://github.com/serai-dex/serai/blob/develop/networks/bitcoin/src/crypto.rs

3) Our bitcoin library was also audited can be used today for FROST-signing Bitcoin transactions. There is already one wallet doing so.

4) As for the future, I do have a variety of comments. I personally regret not making our FROST implementation PV (we assume if you're handling the protocol transcript, you are in fact a signer) as that complicates the logic within Serai (#588). There's also misc technical comments (#264) as there always is. I may or not handle those within the next few months.

5) Regarding any BIPs, if there is a BIP with consensus for FROST (not an official BIP, yet a BIP candidate with consensus on content among the FROST community), I'd be willing to ensure bitcoin-serai implements it (when that occurs its own question).

I'm closing this issue as there's not an active work associated with it. Feel free to reach out privately, ask that I email you if that's your preferred way to communicate, or continue discussion here if you'd like.

[kayabaNerve]

As one further note, Serai represents a fundamentally distinct use-case from wallet self-custody solutions. I say the following with that as necessary context.

Non-robust non-PV protocols are annoying as hell to manage, and I'm unsure the protocols necessary to resolve their flaws are worthwhile at this scale. If I could, I believe I'd 100x my costs and adopt a linear-complexity robust scheme rather than use FROST in this setting. Doing so would remove the need for an intelligent re-attempt protocol (ROAST, Serai's own reattempt protocol) and remove the need to preserve randomness between rounds (with all the secure handling bounds associated). I'd prefer the cryptographic complexity to the application-layer complexity. I just can't justify the bandwidth (#453) at this time, nor the security (I never did the security proofs for my proposed protocol premised on class groups).

I'll also note the idea of a teVRF premised on LWE as a way to achieve robust linear-complexity signing protocols, yet there's not an efficient proof for that posited (and suggested parameter sets are largely unclear).