Multisig is a familiar concept to most people in Bitcoin: a multisig transaction requires approval from multiple parties before it can be executed. We distinguish between “N-Of-N” Multi-signature, where the number of parties involved NAnd they all need approval, and “Tea-Of-N” limit signatures, where only a small number Tea Participants need to give approval. Cryptographic schemes such as MuSig, muSig-dn And MuSig2 for multi-signatures and Frost This research developed by Komlo and Goldberg for threshold signatures can reduce transaction costs and improve the privacy of multisig wallets.
So far, 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 intend to advance FROST in the Bitcoin production environment through our recent publication. BIP Draft for ChildKG Distributed key generation protocol.
First of all, what are the benefits of FROST?
Increased privacy and efficiency with MuSig2 and FROST
With MuSig2 and Frost, even though multiple participants contribute to the signing process, the result is a single signature.
This not only gives participants better privacy, but also makes the transaction look more like a normal singlesig-wallet transaction. It also makes the transaction smaller, reducing its size and therefore reducing transaction fees. All great things!
MuSig2 and FROST allow Bitcoin users to operate a multisig wallet with the same transaction costs as a regular single-signature wallet. The cost benefits are especially important for systems with a large number of signers and frequent transactions, such as federated sidechains like liquid Or FedimintUnlike traditional multisig, which leaves a distinct fingerprint that allows blockchain observers to identify a wallet’s transactions, FROST-based wallets are indistinguishable from regular single-signature wallets on the blockchain. Therefore, they offer privacy improvements compared to traditional multisig wallets.
While MuSig2 has been adopted by the Bitcoin industry, as far as we know, the same cannot be said for FROST. This may be surprising, as several implementations of FROST exist, such as ZF Frost (by Zcash Foundation), secp256kfun (by Lloyd Fournier), and an experimental implementation libsecp256k1-zkp There is also an IETF specification for FROST (by Jesse Posner and Blockstream Research), RFC 9591 (It is however 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 than MuSig2’s.
The unsolved puzzle of FROST in production systems
FROST consists mainly of two parts: key generation and signing. While the signing process is very similar to MuSig2, key generation is significantly more complex than MuSig2. Key generation in FROST is 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 malicious or hacked, the FROST wallet is at risk of being emptied.
- Distributed key generation (DKG), while eliminating the need for a trusted dealer, presents its own challenges: it requires all participants to engage in an interactive key generation “ceremony” before signing can begin.
Main Challenge: Consent
DKGs typically require secure (i.e., authenticated and encrypted) channels between participants to distribute secret shares to individual signers, and a secure agreement mechanism. The purpose of the secure agreement mechanism is to ensure that all participants eventually reach consensus on the results of the DKG, including not only parameters such as the generated threshold public key, but also whether no errors occurred and the ceremony was not interrupted by a misbehaving participant.
While the IETF specification considers DKG completely out of scope, the FROST implementations mentioned above do not implement secure agreement, leaving this task to the library user. But implementing agreement is not easy: countless protocols and types of agreement exist, ranging from simple echo broadcast schemes to full-blown Byzantine consensus protocols, and their security and availability guarantees vary considerably, and sometimes subtly.
Despite the confusion caused by this jungle of agreement protocols, the exact nature of the agreements on which DKG relies is often not clearly explained to engineers, leaving them in the dark.
ChillDKG: A standalone DKG for Frost
To overcome this obstacle, we propose ChillDKG, a new “ready-to-use” DKG protocol optimized for use in FROST (contract) 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 main feature of ChillDKG is that it is standalone: the establishment of secure communication and secure agreement is done within the protocol, while all this underlying complexity is hidden behind a simple and hard to abuse API. As a result, ChillDKG is ready for use in practice and does not rely on any setup assumptions, except that each signer has a decided set of co-signers identified by individual public keys. ChillDKG is based on the SimplePassword Protocol, whose design and formal security proof have involved Blockstream Research, see, Crypto 2023 paper “Practical Schnorr threshold signatures without algebraic group models” by Chu, Gerhart, Ruffing (Blockstream Research), and Schröder
Additional design goals of ChildDKG include:
- Wide applicability: ChildDKG supports a variety of scenarios, including one where the signing devices are owned and connected by a single person, and another where multiple owners manage the devices from different locations.
- Simple backup: Instead of backing up secret information obtained from other signers to a secure location, ChillDKG allows restoring wallets only from the device seed and public data that is the same for all DKG participants. As a result, an attacker gaining 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.
CHILLDKG BIP It is currently in the draft stage, and we are seeking feedback on design choices and implementation details. While the specification is nearly complete, it lacks test vectors, and we are considering adding some additional features (e.g., “identifiable revocation”). Once finalized, the ChillDKG BIP can be used in conjunction with the BIP for FROST signatures to instantiate the complete FROST protocol.
This is a guest post written by Jonas Nick, Kiara Bickers and Tim Ruffing. The opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
