Multisig is a familiar concept to most in Bitcoin: a multisig transaction requires approval from multiple parties before it can be executed. We distinguish between “N-by-N“multi-signatures, where the number of parties involved Nand they must all give their approval, and “T-by-N“threshold signatures, where only a smaller number of T must be approved by participants. Cryptographic schemes such as MuSig, MuSig-DN And In Sig2 for multi-signatures and FROST by Komlo and Goldberg for threshold signatures can reduce transaction costs and improve the privacy of multisig wallets.
Until now, FROST has only been used in experimental implementations in the Bitcoin Community. In this post, we explain why this is the case and how we plan to improve FROST in a Bitcoin production environment through our recent publication of a BIP design for the ChillDKG distributed key generation protocol.
First of all, what are the advantages of FROST?
Privacy and efficiency gains with MuSig2 and FROST
With MuSig2 and FROST, even if multiple participants contribute to the signing process, the result is a single signature.
Not only does this give more privacy to the participants by making the transaction look like a regular singlesig wallet transaction, it also shrinks the transaction, reducing its size and thus lowering transaction fees. All great!
MuSig2 and FROST allow Bitcoin users to use a multisig wallet with the same transaction fees as a regular single-signature wallet. The cost benefits are especially significant for systems with a large number of signers and frequent transactions, such as federated sidechains like Liquid or Confection. Unlike traditional multisig, which leaves a distinct fingerprint that allows blockchain observers to identify transactions from the wallet, FROST-based wallets are indistinguishable from regular single-signature wallets on the blockchain. Therefore, they offer an improvement in privacy compared to traditional multisig wallets.
While MuSig2 has been adopted by the Bitcoin industry, the same cannot be said for FROST as far as we know. This may be surprising, given the existence of multiple FROST implementations, such as in ZF-FRANCE (by the Zcash Foundation), secp256kplezier (by Lloyd Fournier), and an experimental implementation in libsecp256k1-zkp (by Jesse Posner and Blockstream Research). There is even an IETF specification for FROST, RFC-9591 (although it is not compatible with Bitcoin due to Taproot tweaking and x-only public keys). One of the most plausible explanations is that FROST’s key generation process is significantly more complex compared to MuSig2.
The Unsolved Puzzle of FROST in Production Systems
FROST essentially consists of two parts: key generation and signing. While the signing process is very similar to MuSig2, key generation is significantly more involved than in MuSig2. Key generation in FROST is either trusted or distributed:
- Trusted key generation involves a “trusted dealer” who generates the key and distributes keyshares to signers. The dealer represents a single point of failure: if it is malicious or hacked, the FROST wallet is at risk of being emptied.
- While Distributed Key Generation (DKG) eliminates the need for a trusted dealer, it also comes with its own challenges: all participants must take part in an interactive key generation ceremony before signing can begin.
The core challenge: agreement
DKG typically requires secure (i.e., authenticated and encrypted) channels between participants to deliver secret shares to individual signers, and a secure agreement mechanism. The purpose of the secure agreement mechanism is to ensure that all participants ultimately agree on the results of the DKG, which include not only parameters such as the generated public key threshold, but also that no error has occurred and the ceremony has not been disrupted by a misbehaving participant.
While the IETF specification considers DKG completely out of scope, the FROST implementations listed above do not implement secure agreement, leaving this task to the library user. But agreement is not trivial to implement: numerous protocols and flavors of agreement exist, ranging from simple echo-broadcast schemes to full-fledged Byzantine consensus protocols, and their security and availability guarantees differ significantly, and sometimes subtly.
Despite the confusion that can arise from this jungle of agreement protocols, the exact nature of the agreement on which DKG relies is often not clearly communicated to engineers, leaving them in the dark.
ChillDKG: an independent DKG for FROST
To overcome this obstacle, we propose ChillDKG, a new “off-the-shelf” DKG protocol tailored for use in FROST (provisional version). We provide a detailed description in the form of a draft Bitcoin Improvement Proposal (BIP), which is intended to serve as a specification for implementers.
The key feature of ChillDKG is that it is self-contained: setting up secure communications and secure agreements happens within the protocol, while all of this underlying complexity is hidden behind a simple and hard-to-abuse API. As a result, ChillDKG is ready for real-world use and does not rely on any setup assumptions other than that each signer has decided on the set of co-signers as identified by individual public keys. ChillDKG is based on the SimplPedPop protocol, whose design and formal security proof Blockstream Research has been involved in, see the CRYPTO 2023 paper “Practical Schnorr threshold signatures without the algebraic group model” by Chu, Gerhart, Ruffing (Blockstream Research) and Schröder
Additional design goals for ChillDKG include:
- Wide Applicability: ChillDKG supports a wide range of scenarios, from scenarios where the signing devices are owned and connected by one person to scenarios where multiple owners manage the devices from different locations.
- Simple Backups: Instead of requiring secrets received from other signers to be backed up to a secure location, ChillDKG allows the wallet to be restored only from the device seed and public data that are the same for all DKG participants. Consequently, an attacker who gains access to the public backup data does not obtain the secret signing key, and if a user loses their backup, they can request it from another honest signer.
The ChillDKG-BIP is currently in the concept phase and we are seeking feedback on design choices and implementation details. While the specification is largely complete, it lacks test vectors and we are considering adding some additional features (e.g. “identifiable aborts”). Once finalized, the ChillDKG BIP can be used in conjunction with a FROST signing BIP to instantiate the full FROST protocol.
This is a guest post by Jonas Nick, Kiara Bickers, and Tim Ruffing. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.