Multi-signature is a concept that most Bitcoin users are familiar with: a multi-signature transaction requires approval from multiple parties before it can be executed. We distinguish betweenN-to-NMultiple signatures, where the number of parties involved is NThey all need approval, andT-to-N“Threshold signatures, where the number of signatures is only the smallest” T Participants must agree to cryptographic schemes such as MuSig, MuSig-DN And In Sage2 For multiple signatures and frost By using threshold signatures developed by Komlo and Goldberg, the transaction cost can be reduced and the privacy of multi-signature wallets can be improved.
So far, in the Bitcoin community, FROST has only been used in experimental applications. In this post, we explain why this is the case and how we aim to develop FROST in a Bitcoin production environment with our recent deployment of ChillDKG Business Plan Draft Distributed Key Generation Protocol.
First, what are the benefits of FROST?
Privacy and Efficiency Gains with MuSig2 and FROST
With MuSig2 and FROST, even though many participants contribute to the signing process, the result is a single signature.
Not only does this provide better privacy for participants by making the transaction appear like a regular transaction in a single signature wallet, it also reduces the transaction size and therefore reduces transaction fees. All great stuff!
MuSig2 and FROST allow Bitcoin users to operate a multi-signature wallet at the same transaction cost as a regular single-signature wallet. The cost benefits are particularly important for systems with a large number of signers and frequent transactions, such as federated sidechains like liquid or feedUnlike traditional multi-signature wallets, which leave a unique fingerprint that allows blockchain observers to identify wallet transactions, FROST-based wallets are indistinguishable from regular single-signature wallets on the blockchain. Thus, they offer improved privacy compared to traditional multi-signature wallets.
While MuSig2 has been embraced by the Bitcoin industry, the same cannot be said for FROST as far as we know. This may come as a surprise, given that there are many applications of FROST, such as ZF Frost (By Zcash Foundation), secp256kfun (By Lloyd Fournier), and a pilot implementation in libsecp256k1-zkp (By Jesse Posner and Blockstream Research) There’s even an IETF specification for FROST, Request for comments #9591 (Although it is not compatible with Bitcoin due to the Taproot modification and only x-public keys.) One of the most likely explanations is that the key generation process in FROST is significantly more complex than in MuSig2.
The Unsolved FROST Puzzle in Production Systems
FROST basically consists of two parts: key generation and signing. While the signing process is very similar to the key generation process in MuSig2, key generation requires a bit more involvement than the key generation process in MuSig2. Key generation in FROST is either trusted or distributed:
- The trusted key generation process involves a “trusted merchant” who generates the key and distributes key shares to the signatories. The merchant represents a single point of failure: if it is malicious or compromised, the FROST wallet is at risk of being emptied.
- Although the distributed key generation (DKG) process eliminates the need for a trusted merchant, it presents its own challenges: all participants must participate in an interactive key generation “ceremony” before signing can begin.
The main challenge: agreement
A DKG typically requires secure (i.e., authenticated and encrypted) channels between participants to deliver secret shares to individual signatories, and a secure agreement mechanism. The purpose of the secure agreement mechanism is to ensure that all participants ultimately reach agreement on the outcome of the DKG, which includes not only parameters such as the resulting public key, but also whether no error occurred and the ceremony was not disrupted by a misbehaving participant.
While the IETF spec considers DKG completely out of scope, the FROST implementations mentioned above do not implement a secure agreement, leaving that task to the library user. But the agreement is not easy to implement: there are countless protocols and flavors of agreement, ranging from simple echo-broadcast schemes to full-fledged Byzantine consensus protocols, and the guarantees of security and availability vary widely, sometimes subtly.
Despite the confusion that can arise from this jungle of agreement protocols, the exact flavor of the agreement that DKG relies on is often not clearly communicated to engineers, leaving them in the dark.
ChillDKG: Standalone DKG for FROST
To overcome this obstacle, we propose ChillDKG, a new “off-the-shelf” DKG protocol designed for use in FROST (Draft). 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 advantage of ChillDKG is that it is independent: secure communications and secure agreement are established within the protocol, while all of this underlying complexity is hidden behind a simple API that is difficult to abuse. As a result, ChillDKG is practically ready to use and does not rely on any setup assumptions, except that each signer has decided on the set of co-signers as determined by their individual public keys. ChillDKG is based on the SimplPedPop protocol, which Blockstream Research co-designed and formally demonstrated its security, see the CRYPTO 2023 paper “Schnorr threshold signatures without algebraic group modelBy Chu, Gerhart, Ruffing (Blockstream Research), and Schroeder
Additional goals for the design of ChillDKG include:
- Broad Applicability: ChillDKG supports a wide range of scenarios, from those where signature devices are owned and connected by a single individual to those where multiple owners manage devices from distinct locations.
- Simple Backups: Instead of having to back up secrets received from other signers to a safe location, ChillDKG allows the wallet to be restored only from the device seed and public data that are the same for all DKG participants. Thus, an attacker who gains access to the public backup data does not get the secret signing key, and if a user loses their backup, they can request it from another honest signer.
the Chill D K G B I B It is currently in draft stage, and we are seeking feedback on design choices and implementation details. While the specification is mostly finished, it lacks test vectors, and we are considering adding some additional features (e.g., “selectable aborts”). Once finalized, the ChillDKG BIP can be used in conjunction with the FROST signature BIP to create an instance of the full FROST protocol.
This is a guest post by Jonas Nick, Chiara Beckers, and Tim Ruffing. The opinions expressed in this post are entirely their own and do not necessarily reflect the views of BTC Inc or Bitcoin Magazine.
Comments are closed, but trackbacks and pingbacks are open.