Cooperative Signing

What Is Cooperative Signing?

Cooperative signing is a cryptographic technique where multiple participants interact to produce a single valid signature for a message. Each participant holds a key share rather than the complete private key, and contributes a partial signature during a structured communication protocol. These partial signatures are then aggregated into one final signature that verifies against a single aggregate public key.

The critical property is that the full private key never exists in any single location at any point in the process. During key generation, each participant creates their own secret polynomial and exchanges shares with others. During signing, participants exchange commitments and partial signatures. The aggregate signature that emerges is mathematically identical to a standard single-key signature: no verifier can tell whether one person or a hundred people cooperated to produce it.

This stands in contrast to traditional Bitcoin multisig, where each party signs independently using OP_CHECKMULTISIG or OP_CHECKSIGADD, producing multiple separate signatures that are all included in the transaction witness. Cooperative signing moves the policy enforcement from Bitcoin Script to the cryptographic layer, collapsing what would be multiple signatures into one.

How It Works

Cooperative signing protocols follow a general structure: a one-time key generation phase, followed by a multi-round signing protocol for each message. The two primary protocols used in Bitcoin are MuSig2 (specified in BIP-327) for n-of-n signing and FROST (standardized in RFC 9591) for threshold signing.

Key Generation

Before any signing can occur, participants must establish their key shares and compute the aggregate public key. The approach differs between protocols:

• MuSig2 uses non-interactive key aggregation: each signer already has a standard key pair, and the aggregate public key is computed by multiplying each participant's public key by a coefficient derived from hashing all participants' keys together. This prevents rogue key attacks where a malicious party could choose their key to cancel out honest participants' contributions.
• FROST uses distributed key generation (DKG) based on Pedersen's verifiable secret sharing. Each participant generates a random polynomial of degree (t-1), broadcasts commitments to the polynomial coefficients, and sends secret shares to every other participant over encrypted channels. Recipients verify received shares against the commitments. The group private key is never constructed.

Round 1: Nonce Commitment

Each participating signer generates a pair of random nonces (secret scalars) and computes the corresponding elliptic curve points as commitments. These commitments are broadcast to all other participants or sent to a coordinator. The use of two nonces per signer (rather than one) is a deliberate design choice that defeats Wagner's birthday attack on nonce aggregation.

In MuSig2, this round produces a 66-byte public nonce per signer (two 33-byte compressed points). In FROST, participants generate a hiding nonce and a binding nonce, with the binding nonce tied to all participants' commitments via a hash-derived binding factor.

Nonce commitments can be pre-shared before the message to sign is known, effectively reducing the online signing protocol to a single round.

Round 2: Partial Signature Generation

Once all nonce commitments are collected, each signer computes the aggregate nonce from all contributions and produces a partial signature using their secret key share, their secret nonces, and the aggregate nonce. The partial signature is a single scalar value.

In FROST, each signer also computes their Lagrange interpolation coefficient for the specific set of participating signers. This coefficient adjusts their key share contribution so that any valid subset of t signers produces the same aggregate signature.

// FROST partial signature computation (simplified)
sig_share = hiding_nonce
  + (binding_nonce * binding_factor)
  + (lagrange_coefficient * secret_share * challenge)

// MuSig2 partial signature computation (simplified)
sig_share = secret_nonce_1
  + (secret_nonce_2 * nonce_coefficient)
  + (key_agg_coefficient * secret_key * challenge)

Aggregation

A coordinator (or any participant) collects all partial signatures and sums them to produce the final 64-byte Schnorr signature. Optionally, each partial signature can be individually verified before aggregation to identify any misbehaving signer. The final signature is then verified against the aggregate public key using the standard BIP-340 verification algorithm.

On the Bitcoin blockchain, this signature occupies exactly the same space as a single-key Taproot spend: 64 bytes in the witness, regardless of whether 2 or 100 parties cooperated to produce it.

Cooperative Signing vs. Multisig

The practical differences between cooperative signing and script-based multisig are significant:

For a deeper comparison of custody architectures, see the research article on MPC vs. multisig custody.

Use Cases

Statechains and Spark

Spark uses cooperative signing as the foundation of its statechain model. Each virtual UTXO is controlled by a two-party signing arrangement: the user holds one key share, and a group of independent Spark Operators collectively hold the other via FROST threshold signing. Neither the user nor any subset of operators can spend funds alone.

When ownership transfers, the operators perform a key rotation: they generate a new key share for the recipient and adjust their own share so the aggregate public key remains unchanged. The previous owner's key share becomes cryptographically invalid. From Bitcoin's perspective, the on-chain UTXO never moves. This enables instant, off-chain transfers with near-zero cost.

For the full architecture, see Statechains: Bitcoin Scaling Deep Dive and What Is Spark.

Taproot Wallets

Cooperative signing enables multi-party Taproot wallets where the key-path spend looks identical to a single-user wallet on-chain. Institutional custodians can implement 2-of-3 or 3-of-5 policies using FROST while paying fees comparable to a single-signature transaction. The threshold structure remains completely hidden unless a script-path fallback is used.

Lightning Channel Closes

Lightning channels using Taproot channels can leverage MuSig2 for cooperative closes. The cooperative close transaction appears on-chain as a standard single-key Taproot spend, revealing nothing about the channel's two-party structure and reducing fees compared to legacy channel formats.

Corporate Treasury Management

Organizations requiring multi-party authorization for Bitcoin transactions can use FROST to implement flexible spending policies. A 3-of-5 FROST configuration among board members provides fault tolerance (any two can be unavailable) while maintaining full on-chain privacy. Key rotation allows refreshing shares if a member's device is compromised, without changing the public key or moving funds on-chain.

Why It Matters

Cooperative signing solves a fundamental tension in Bitcoin custody: the need for multi-party security without sacrificing privacy or efficiency. Traditional multisig reveals the exact custody structure to every observer on the blockchain, enabling chain analysis firms to fingerprint wallet providers and cluster addresses. Cooperative signing eliminates this information leak entirely.

The fee savings compound at scale. A 3-of-5 FROST spend uses roughly 80% less witness data than the equivalent P2WSH multisig transaction. For high-volume operations like exchanges or payment processors, this translates directly to lower operating costs.

For protocols like Spark, cooperative signing enables a trust model that would be impossible with traditional multisig: distributing the statechain entity across multiple independent operators using FROST, so that a 1-of-n honesty assumption replaces reliance on a single trusted party.

Risks and Considerations

Nonce Reuse Is Catastrophic

If a signer ever reuses a nonce pair across two different signing sessions, their secret key share can be extracted algebraically. This is not a theoretical concern: it is a fundamental mathematical property of Schnorr signatures. Both MuSig2 and FROST mandate that nonces be generated from high-quality randomness and deleted immediately after signing. Deterministic nonce generation, which is safe in single-signature contexts, becomes dangerous in cooperative signing because an adversary can replay protocol messages to force nonce reuse.

Interactivity Requirements

Unlike script-based multisig, where each signer can produce their signature independently and offline, cooperative signing requires signers to participate in a structured communication protocol. All participating signers must exchange nonce commitments before any partial signatures can be produced. This interactivity can be challenging for cold storage setups or air-gapped devices where network communication is intentionally restricted.

Coordinator Trust

While the coordinator in FROST cannot forge signatures or learn secret key shares, a malicious coordinator can disrupt the protocol by withholding or altering messages. The security model assumes authenticated communication channels between participants. A dishonest participant can also disrupt signing by contributing an invalid partial signature, though this is detectable through individual share verification.

Implementation Maturity

Cooperative signing protocols are newer than traditional multisig, which has over a decade of production deployment on Bitcoin. MuSig2 was specified in BIP-327 (merged March 2023), and FROST was standardized in RFC 9591 (published June 2024) with a Bitcoin-specific BIP-445 still in development. While no exploits have been found in FROST's Schnorr-based design, the protocol has less battle-testing than OP_CHECKMULTISIG. For a broader view of threshold signature schemes, see the FROST threshold signatures explained research article.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.