Threshold Signature Scheme (TSS)

The process where multiple participants collaboratively create a public/private key pair without any single entity ever learning the full private key. Each participant generates and securely shares a secret share. The collective public key is derived from these shares, while the corresponding private key remains virtual and never materializes in one place.

• Prevents Single Points of Failure: No central key custodian.
• Foundation for Trust: Establishes the initial, secure state for the TSS system.

The core operation where a subset of participants, meeting a predefined threshold (t-of-n), collaborates to produce a valid signature. For example, in a 2-of-3 scheme, any two of three parties can sign. The signature is generated through a multi-party computation (MPC) protocol, combining partial signatures from each participant's secret share. The full private key is never reconstructed during this process.

• Flexible Security Policies: Enforces quorum-based authorization.
• Native Multi-Sig Security: Provides security similar to multi-signature wallets without on-chain script overhead.

A security enhancement that periodically refreshes the secret shares held by participants without changing the underlying group public key or requiring a new Distributed Key Generation (DKG). This process mitigates mobile adversary threats, where an attacker slowly compromises nodes over time. By refreshing shares, previously compromised shares become useless, limiting the attacker's window of opportunity to reach the threshold.

• Forward Secrecy: Compromised past shares cannot be used for future signatures.
• Enhanced Long-Term Security: Critical for systems requiring high durability against persistent attacks.

A fundamental security property where the signing authority is distributed across multiple independent parties or machines. The private key does not exist in its complete form anywhere in the system, not even transiently in memory. This eliminates the risk of a single private key compromise that could lead to total fund loss, a vulnerability inherent in traditional hot wallets and some multi-signature setups.

• Eliminates Key Theft Target: Attackers cannot exfiltrate a complete key.
• Resilience: The system remains operational as long as the threshold of honest participants is met.

TSS generates a single, standard cryptographic signature (e.g., ECDSA, EdDSA) that is indistinguishable from one created by a regular private key. This results in significant gas savings and reduced blockchain footprint compared to native multi-signature schemes (like Bitcoin's CHECKMULTISIG or Ethereum's Gnosis Safe), which require publishing multiple signatures and complex verification logic on-chain.

• Lower Transaction Costs: Appears as a single-signer transaction.
• Broad Compatibility: Works with any blockchain or application expecting a standard signature format.

A critical distinction in TSS implementations. A trusted setup requires a trusted dealer to generate and distribute secret shares, creating a central point of failure during initialization. A trustless setup uses a Distributed Key Generation (DKG) protocol where no dealer is needed; participants jointly establish the key. For maximum security in decentralized systems, a trustless DKG is essential to avoid a single entity knowing all shares or being able to bias the key generation.

• Trusted Dealer: Simpler but introduces initial trust assumption.
• Trustless DKG: More complex but provides security from the very first step.

TSS changes the security model compared to on-chain multi-signatures. Pros: No on-chain footprint for the signing scheme, reducing blockchain-specific attack vectors and lowering fees. Cons: Introduces a complex, interactive off-chain protocol with new risks: network communication can be intercepted, and participants must run correct, synchronized software. In contrast, a 2-of-3 multisig's logic is enforced immutably on-chain, but its structure and signers are public.

To defend against an attacker slowly compromising shares over time, advanced TSS implementations use Proactive Secret Sharing. This involves periodically executing a protocol to refresh the secret shares without changing the underlying public key. This adds operational overhead but is essential for long-lived keys. Without it, the system's security degrades over time, as compromising t participants eventually breaks the scheme.

Modern TSS protocols like GG20 enable non-interactive signing for most operations, a major usability improvement. However, the initial setup and any resharing remain interactive and communication-heavy. Signing latency and throughput are constrained by the slowest participant's network and computational resources. This trade-off favors security (distributed trust) over the raw performance of a single, centralized signer.

A key trade-off is reduced on-chain auditability. With a traditional multisig, every approving signature is visible on-chain, providing clear accountability. In TSS, a single, standard-looking signature is produced, obscuring which subset of participants authorized it. This requires robust off-chain attestation logs and governance to track approval, shifting the accountability framework from the transparent blockchain to private operational procedures.

Multi-Party Computation (MPC) is the broader cryptographic framework that enables a group of parties to jointly compute a function over their private inputs without revealing those inputs to each other. TSS is a specific application of MPC for the function of generating and using digital signatures.

• Foundation: TSS protocols are built upon MPC techniques.
• Privacy: No single party ever has access to the complete private key.
• Versatility: MPC is used for private auctions, secure data analysis, and privacy-preserving machine learning beyond just signatures.

Shamir's Secret Sharing (SSS) is a method for splitting a secret (like a private key) into multiple shares, where a specified threshold number of shares is required to reconstruct the original secret. It is often contrasted with TSS.

• Key Difference: SSS requires reconstructing the full key to sign, creating a single point of failure during signing. TSS signs without ever reconstructing the key.
• Use Case: SSS is excellent for secure backup and storage but is less ideal for active, frequent signing operations compared to TSS.

Multi-signature (Multisig) is a wallet technology that requires multiple private keys to authorize a transaction. It is a higher-level, on-chain construct, whereas TSS is a lower-level cryptographic protocol.

• On-Chain vs. Off-Chain: Multisig logic and participant public keys are recorded on the blockchain. TSS operations occur off-chain, producing a single, standard-looking signature.
• Transaction Footprint: A 2-of-3 multisig transaction is larger and more expensive than a transaction signed by a single TSS-generated signature.

Distributed Key Generation (DKG) is a critical phase within a TSS protocol where the participating parties collaboratively generate a public/private key pair without any single entity ever knowing the complete private key.

• Foundation for Security: A secure DKG protocol is essential; a compromised DKG can break the entire system.
• Output: Each party ends up with a secret share of the private key and the shared public key. The full private key never exists in one place.

Schnorr and BLS are specific signature algorithms that are particularly well-suited for TSS due to their linear properties.

• Schnorr Signatures: Used in Bitcoin's Taproot upgrade. Enable signature aggregation, where multiple signatures can be combined into one, aligning perfectly with TSS outputs.
• BLS Signatures: Allow even more efficient aggregation across multiple messages and signers. Commonly used in Ethereum's proof-of-stake consensus (e.g., Ethereum 2.0 validators) and many TSS implementations for their efficiency.