Multisig is a familiar concept to most Bitcoin users. A multisig transaction requires approval from multiple parties before it can be executed.yeah-of-yeah“In multi-signatures, the number of parties involved is yeahand they all have to approve, andt-of-yeah“Threshold signatures” are smaller t Participants must approve the encryption. Music DN and Music 2 Multi-signing and frost Threshold signatures by Komlo and Goldberg can reduce transaction costs and improve privacy in multi-sig wallets.
To date, FROST has only been used in experimental implementations in the Bitcoin community. In this article, we explain why this is the case and how we aim to evolve FROST into production Bitcoin using our recent release. ChillDKG’s BIP draft A distributed key generation protocol.
Firstly, what are the benefits of FROST?
MuSig2 and FROST for improved privacy and efficiency
In MuSig2 and FROST, even if multiple participants contribute to the signing process, the result is a single signature.
This not only increases privacy for participants as the transactions look like normal single-sig wallet transactions, but also lowers transaction fees as transactions are cut down and reduced in size. All great!
MuSig2 and FROST allow Bitcoin users to operate multi-signature wallets with the same transaction costs as regular single-signature wallets. The cost benefits are especially evident in systems with large numbers of signers and frequent transactions, such as federated sidechains such as: liquid or Feddy MintWhile traditional multi-sig leaves a clear fingerprint that allows blockchain observers to identify wallet transactions, FROST-based wallets are indistinguishable from regular single-signature wallets on the blockchain, thus providing improved privacy compared to traditional multi-sig wallets.
While MuSig2 has been adopted by the Bitcoin industry, as far as we know, the same cannot be said for FROST, which may be surprising given the existence of multiple FROST implementations, including: ZF Frost (By the Zcash Foundation) secp256kfun (by Lloyd Fournier) and experimental implementations libsecp256k1-zkp FROST (by Jesse Posner and Blockstream Research) also has an IETF specification. See RFC9591 (However, it is not compatible with Bitcoin due to Taproot tweaks and x-only public keys.) One plausible explanation is that FROST’s key generation process is significantly more complicated than MuSig2’s.
Unsolved puzzles of FROST in production systems
FROST essentially consists of two parts: key generation and signing. The signing process is very similar to MuSig2, but key generation is significantly more complex than in MuSig2. Key generation in FROST can be either trusted or distributed.
- Trusted key generation involves a “trusted dealer” that generates keys and distributes key shares to signers. The dealer represents a single point of failure – if compromised by a bad actor or hacked, there is a risk that your FROST wallet will be emptied.
- Distributed key generation (DKG) removes the need for a trusted dealer, but has its own challenges in that it requires all participants to participate in running an interactive key generation “ceremony” before signing can begin.
Main challenge: Agreement
DKGs typically require a secure (i.e., authenticated and encrypted) channel between participants to distribute secret shares to individual signers, as well as a secure consensus mechanism. The goal of the secure consensus mechanism is to ensure that all participants eventually reach agreement on the outcome of the DKG, including parameters such as the generated threshold public keys, as well as whether no errors occurred and whether the ceremony was not disrupted by a dishonest participant.
While the IETF specification considers DKG completely out of scope, the FROST implementation mentioned above does not implement secure agreement, leaving this task to library users. Implementing agreement is not trivial, however: a myriad of protocols and agreement types exist, ranging from simple echo broadcast schemes to full-blown Byzantine consensus protocols, with widely and sometimes subtly different guarantees on security and availability.
Despite the potential confusion caused by the jungle of agreement protocols, the exact content of the agreements on which DKG relies is often not clearly communicated to engineers, leaving them in the dark.
ChillDKG: A standalone DKG for FROST
To overcome this obstacle, we developed FROST (draft) provides a detailed explanation in the form of a draft Bitcoin Improvement Proposal (BIP) that is intended to serve as a specification for implementers.
A key feature of ChillDKG is that it is standalone: secure communication and establishing secure agreements are done within the protocol, and all this underlying complexity is hidden behind simple and hard-to-misuse APIs. As a result, ChillDKG is ready for production use and does not depend on any setup assumptions, except that each signer has determined the set of co-signers identified by their individual public keys. ChillDKG is based on the SimplPedPop protocol, and Blockstream Research was involved in its design and formal security proof; see the CRYPTO 2023 paper.Practical Schnorr threshold signatures without using algebraic group models“Chu, Gerhart, Ruffing (Blockstream Research), by Schröder”
Other design goals for ChillDKG include:
- Broad applicability: ChillDKG supports a wide range of scenarios, from those where the signing device is owned and connected by a single individual to those where multiple owners manage the device from separate locations.
- Simple backup: Instead of backing up secrets received from other signers in a safe place, ChillDKG allows wallets to be restored only from the device seed and public data that are common to all DKG participants. As a result, an attacker who has access to the public backup data cannot obtain the private signing key, and if a user loses the backup, they can request it from another legitimate signer.
of Chill DKG BIP We are currently in the draft stage, seeking feedback on design choices and implementation details. The specification is nearly complete, but is missing test vectors and we are considering adding some additional features (such as “distinguishable aborts”). Once complete, the ChillDKG BIPs can be used in combination with the BIPs for FROST signing to instantiate the entire FROST protocol.
This is a guest post by Jonas Nick, Kiara Bickers and Tim Ruffing. The opinions expressed here are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
