Bitcoin Signature Schemes Compared: ECDSA, Schnorr, FROST, MuSig2

Bitcoin Signature Schemes at a Glance

Bitcoin relies on digital signatures to authorize every transaction. The original protocol used ECDSA exclusively, but the Taproot upgrade in November 2021 introduced Schnorr signatures (BIP 340), unlocking a new generation of multisignature and threshold protocols. Two of those protocols have emerged as particularly significant: MuSig2 for n-of-n multisig and FROST for t-of-n threshold signing.

The following table summarizes the core properties of each scheme. Every scheme operates on the same secp256k1 elliptic curve that Bitcoin has used since its genesis block.

ECDSA: The Original Bitcoin Signature

The Elliptic Curve Digital Signature Algorithm has secured Bitcoin transactions since the genesis block in 2009. ECDSA signatures are DER-encoded and variable-length, typically 70 to 72 bytes depending on whether the r and s values require padding bytes. The compressed public key is 33 bytes.

ECDSA works reliably for single-signer transactions, but it has structural limitations. It lacks the linearity property needed for native key aggregation, making multisig constructions require OP_CHECKMULTISIG, which places every public key and signature on-chain. A 3-of-5 ECDSA multisig exposes all five public keys and three signatures in the transaction, increasing both cost and privacy leakage.

ECDSA signatures are also inherently malleable: a third party can transform a valid signature into a different valid signature without knowing the private key. Bitcoin addressed this through SegWit (BIP 141), which moved signatures out of the transaction ID calculation, and BIP 66, which enforced strict DER encoding.

Schnorr Signatures: The Taproot Foundation

BIP 340 specifies Schnorr signatures over secp256k1 and was activated as part of the Taproot soft fork at block 709,632 (November 14, 2021). The specification was authored by Pieter Wuille, Jonas Nick, and Tim Ruffing.

Schnorr signatures are fixed at 64 bytes: 32 bytes for the x-coordinate of the nonce point R, plus 32 bytes for the scalar s. Public keys use x-only encoding at 32 bytes. This saves roughly 8 to 9 bytes per signature and 1 byte per public key compared to ECDSA, which adds up at scale.

The critical advantage is linearity. Because Schnorr signatures are linear over the key and nonce, multiple parties can combine their individual signatures into a single valid signature for the sum of their public keys. This mathematical property is the foundation for both MuSig2 and FROST. For a deeper technical walkthrough, see our research on Taproot and Schnorr signatures.

Schnorr also supports batch verification: a node can validate multiple signatures simultaneously by combining them into a single elliptic curve equation, significantly accelerating block validation.

MuSig2: Compact n-of-n Multisignatures

MuSig2 (BIP 327) is a two-round multisignature protocol that allows n participants to jointly produce a single 64-byte Schnorr signature. The aggregate public key is a standard 32-byte P2TR key, making an n-of-n MuSig2 spend completely indistinguishable from a single-signer Taproot transaction on-chain. BIP 327 was authored by Jonas Nick, Tim Ruffing, and Elliott Jin at Blockstream Research.

The original MuSig protocol (2018, by Gregory Maxwell, Andrew Poelstra, Yannick Seurin, and Pieter Wuille) required three rounds: commit to nonces, reveal nonces, then exchange partial signatures. MuSig2 eliminates the commitment round while remaining secure even under concurrent signing sessions. The two rounds are: (1) exchange nonces (each nonce is 66 bytes: two 33-byte curve points), and (2) compute and combine partial signatures.

MuSig2 provides full privacy: no on-chain observer can determine whether a transaction was signed by one person or a hundred. This contrasts sharply with legacy ECDSA multisig, where the number of signers and threshold are visible in the script. For more detail on the protocol, see our research on MuSig2 multisignatures.

Adoption is accelerating. Ledger shipped MuSig2 support in Bitcoin App v2.4.0 (April 2025), BitGo has deployed it for Taproot hot wallets, and Bitcoin Core has merged MuSig2 PSBT validation support. The reference implementation lives in libsecp256k1-zkp.

FROST: Threshold Signatures for Bitcoin

FROST (Flexible Round-Optimized Schnorr Threshold signatures) enables t-of-n signing: any t signers from a group of n can produce a valid signature without the remaining n-t participants. The protocol was introduced in 2020 by Chelsea Komlo and Ian Goldberg at the University of Waterloo.

Like MuSig2, FROST produces a standard 64-byte Schnorr signature under a 32-byte aggregate public key. The result is indistinguishable from a single-signer Taproot key-path spend. Unlike MuSig2, FROST supports fault tolerance: if some signers are offline, the remaining participants above the threshold can still sign.

FROST requires a more complex setup phase called Distributed Key Generation (DKG), which splits a secret key into shares using Shamir's Secret Sharing such that no single party ever holds the complete key. Signing itself takes two rounds, matching MuSig2.

FROST was published as RFC 9591 by the IRTF in June 2024. For Bitcoin specifically, BIP 445 (assigned January 2026, authored by Sivaram Dhakshinamoorthy) specifies the FROST3 variant compatible with BIP 340 signatures and BIP 341 Taproot key tweaking. The BIP is currently in draft status. For a full protocol breakdown, see our research on FROST threshold signatures.

FROST vs MuSig2: When to Use Each

MuSig2 and FROST solve different problems. Choosing between them depends on whether you need all signers present (n-of-n) or only a subset (t-of-n).

For custody setups where a lost key cannot block signing, FROST is the better choice. For co-signing workflows where all parties are always available, MuSig2 is simpler to implement and has more mature tooling. The Schnorr and MuSig2 reference guide covers implementation details for developers.

Privacy and On-Chain Efficiency

Legacy ECDSA multisig using OP_CHECKMULTISIG reveals the full signing policy on-chain. A 3-of-5 multisig transaction contains five public keys (165 bytes) and three signatures (roughly 216 bytes), plus script overhead. Anyone analyzing the blockchain can see the exact threshold and count the participants.

Both MuSig2 and FROST eliminate this leakage entirely. The aggregate key and combined signature are identical in format to a standard single-signer Taproot output: 32 bytes for the key, 64 bytes for the signature. Chain analysis tools cannot distinguish a 100-party FROST signing from a single user spending their own funds.

This privacy improvement compounds with cost savings. A Taproot key-path spend (whether single-sig, MuSig2, or FROST) consumes roughly 57.5 virtual bytes for the witness, compared to several hundred vbytes for equivalent ECDSA multisig scripts. For high-throughput systems processing thousands of transactions, the fee reduction is substantial.

FROST in Practice: Spark Protocol

Spark provides a concrete example of FROST deployed at protocol scale. Spark uses a 2-of-2 key structure: the user holds one key, and a set of independent operators (the Spark Entity) collectively hold the other. Within the operator set, FROST enables a threshold signature model where the operators distribute their key share using DKG.

This design means that as long as one operator in the set remains honest, user funds stay secure. Currently, the operator set includes Lightspark and Flashnet, with plans to expand. During transfers, operators generate new FROST key shares for the recipient and destroy the old shares, following a statechain model that enables off-chain ownership transfers without on-chain transactions.

All on-chain settlements produce standard 64-byte Schnorr signatures indistinguishable from ordinary Taproot spends. Users also retain a revocation key that provides unilateral exit to Layer 1 via Taproot script-path spending with relative timelocks, ensuring self-custody guarantees even if all operators go offline.

Implementation Landscape

The following implementations are actively maintained and used in production or advanced testing:

• libsecp256k1-zkp (Blockstream): reference MuSig2 implementation, experimental FROST support
• Bitcoin Core: MuSig2 PSBT validation merged, Schnorr signing since Taproot activation
• Ledger Bitcoin App v2.4.0: full MuSig2 support with parallel signing sessions
• BitGo: MuSig2 deployed for Taproot hot wallets
• ZF FROST (Zcash Foundation): Rust implementation of RFC 9591 with a frost-secp256k1-tr crate for BIP 340 compatibility
• secp256k1-frost (Banca d'Italia): FROST on secp256k1
• Spark: FROST in production for operator key management

For a broader view of cryptographic tooling in Bitcoin development, see the Bitcoin development tools landscape.

Frequently Asked Questions

What is the difference between Schnorr and ECDSA in Bitcoin?

Both operate on the secp256k1 curve, but Schnorr signatures (BIP 340) are fixed at 64 bytes versus ECDSA's variable 70 to 72 bytes, are provably non-malleable, support batch verification for faster node validation, and have a linear structure that enables key aggregation protocols like MuSig2 and FROST. ECDSA lacks linearity, so multisig requires placing all keys and signatures on-chain via OP_CHECKMULTISIG. Schnorr was activated with Taproot in November 2021 at block 709,632.

What is MuSig2 and how does it work?

MuSig2 (BIP 327) is a two-round protocol that lets n parties jointly produce a single 64-byte Schnorr signature. In round one, signers exchange nonces. In round two, each signer computes a partial signature and an aggregator combines them. The result is indistinguishable on-chain from a single-signer transaction, providing both cost savings and complete privacy about the number of signers.

What is the difference between FROST and MuSig2?

MuSig2 is n-of-n: every signer must participate. FROST is t-of-n: only a threshold subset needs to sign. If you have five key holders and want any three to authorize a transaction, you need FROST. If all five must always co-sign, MuSig2 is simpler. Both produce identical 64-byte Schnorr signatures on-chain, but FROST requires a more complex Distributed Key Generation ceremony during setup.

Are FROST and MuSig2 signatures distinguishable from regular Taproot transactions?

No. Both protocols produce standard BIP 340 Schnorr signatures (64 bytes) under standard x-only public keys (32 bytes). On-chain, a 100-party FROST signing looks identical to a single user spending from their own wallet. This is a significant privacy improvement over legacy ECDSA multisig, where the threshold and all public keys are visible in the script.

Does Spark use FROST or MuSig2?

Spark uses FROST for its operator key management. The protocol employs a 2-of-2 structure where one key belongs to the user and the other is distributed among independent operators via FROST. This provides threshold security: as long as one operator remains honest, funds are protected. Users also retain a revocation key for unilateral exit to Bitcoin Layer 1.

Is FROST standardized for Bitcoin?

FROST was published as RFC 9591 by the IRTF in June 2024, covering the generic protocol. For Bitcoin specifically, BIP 445 (assigned January 2026) specifies the FROST3 variant compatible with BIP 340 signatures and BIP 341 Taproot key tweaking. BIP 445 is currently in draft status, while multiple implementations (ZF FROST, libsecp256k1-zkp, Spark) are already in production or advanced development.

What are the security risks of Schnorr-based multisig?

The primary implementation risk is nonce reuse: if a signer uses the same nonce in two different signing sessions, their private key can be extracted. Both MuSig2 and FROST protocols include specific safeguards against this, but implementations must handle nonce state carefully. FROST additionally depends on the security of the DKG ceremony. At the cryptographic level, MuSig2's security relies on the Algebraic One-More Discrete Logarithm (AOMDL) assumption, which is well-studied but stronger than the standard discrete log assumption underlying single Schnorr signatures.

This reference is for informational purposes only and does not constitute financial or security advice. Cryptographic protocol specifications evolve: always consult the latest BIP drafts and implementation documentation before deploying signature schemes in production. Data is based on publicly available specifications and implementation status as of mid-2026.