Narrative Goldmine

BIP-340

9 min read

Properties

Type
  • Class
Resource
  • urn:ngm:class:bip-340
Domain
  • blockchain
Status
  • stable
Maturity
  • established
Quality
  • 0.78
Is a
Part of
Requires
Enables
Generated
  • by: process:vault-migrate/1.0 · at: 2026-09-22T12:41:39.024503178Z
Bridges to
Contrasts with
Implements
Links
    Page resource
    • urn:visionflow:page:bip-340
    Related to
    Standardized by
    Supports
    Uses

    BIP-340 is the Bitcoin Improvement Proposal that standardises Schnorr signatures for use on the Bitcoin network using the secp256k1 elliptic curve, defining a deterministic 64-byte signature scheme that is provably secure in the random oracle model. It introduces x-only 32-byte public key encoding, a tagged hash nonce-generation procedure, and rigorous test vectors to guarantee cross-implementation compatibility. BIP-340 is a strict prerequisite for Taproot (BIP-341) and Tapscript (BIP-342), enabling key aggregation via MuSig2 and linear signature composition that makes multisignature spends indistinguishable on-chain from single-key spends. The proposal represents the most significant cryptographic upgrade to Bitcoin since its inception, substantially improving privacy, efficiency, and the expressiveness of multi-party signing protocols.

    Overview

    • BIP-340 was authored by Pieter Wuille, Jonas Nick, and Tim Ruffing and was activated on the Bitcoin mainnet in November 2021 as part of the Taproot soft fork alongside BIP-341 and BIP-342.
    • The proposal addresses longstanding limitations of ECDSA — the signature algorithm Bitcoin has used since 2009 — by replacing it with Schnorr Signature for the new Taproot output type.
    • Schnorr signatures satisfy a linearity property: the sum of two valid signatures over the sum of two public keys is itself a valid signature. ECDSA does not have this property, which is why on-chain multisig in the legacy system is implemented via OP_CHECKMULTISIG and reveals the number of signing parties on-chain.
    • BIP-340 is domain-confined to the secp256k1 curve (the curve parameters used by Bitcoin since 2009), distinguishing it from related Schnorr constructions such as Ed25519 which use the Edwards25519 curve.
    • The specification is self-contained: it includes Python reference implementations, test vectors, and security proofs sufficient to implement a compliant signer and verifier from scratch.
    • Why it matters:
      • Privacy: aggregate signatures are on-chain indistinguishable from single-key signatures, hiding participant counts in Multi-Signature and Threshold Signature arrangements.
      • Efficiency: 64-byte signatures vs 71–72 bytes for DER-encoded ECDSA; batch verification of n signatures is roughly O(√n) field multiplications rather than O(n).
      • Security: provable security under standard assumptions, vs ECDSA which has no tight reduction; deterministic nonce eliminates the class of key-revealing bugs that compromised the Sony PlayStation 3 ECDSA implementation.
      • Composability: linear structure enables Secure Multi-Party Computation protocols for threshold signing with minimal rounds.

    Key Components

    • Signature Format — 64 bytes: a 32-byte x-coordinate of the nonce point R followed by a 32-byte scalar s. Compact relative to ECDSA’s DER encoding.
    • X-Only Public Keys — Public keys are stored as 32-byte x-coordinates. Since the curve is defined over a prime field, the y-coordinate can be inferred; BIP-340 always chooses the even y, eliminating sign ambiguity. This saves one byte per key and simplifies aggregation arithmetic.
    • Tagged Hash Function — A domain-separated SHA-256 double-hash, H_tag(msg) = SHA256(SHA256(tag) || SHA256(tag) || msg), used for nonce generation and challenge computation. Tags (BIP0340/challenge, BIP0340/nonce, BIP0340/aux) prevent cross-protocol replay.
    • Deterministic Nonce (RFC 6979 variant) — The nonce k is derived from the private key d, the message m, and 32 bytes of auxiliary randomness, using a tagged hash. This prevents the nonce reuse that leaks private keys in naive ECDSA implementations.
    • Signing Algorithm — Compute R = k·G; if R has odd y-coordinate, negate k; compute e = H_challenge(R.x || P || m); compute s = k + e·d mod n; output (R.x, s).
    • Verification Algorithm — Compute e = H_challenge(R.x || P || m); verify s·G = R + e·P; check R.x matches the serialised value.
    • Batch Verification — Multiple (message, pubkey, signature) triples can be verified simultaneously using a random linear combination, yielding significant speedups for nodes validating blocks.
    • Test Vectors — The BIP includes 16 signing test vectors and 18 verification test vectors (including deliberate failure cases) to ensure cross-implementation fidelity.
    • Security Model — Proven SUF-CMA secure (strongly unforgeable under chosen-message attack) in the random oracle model under the discrete-logarithm assumption on secp256k1.

    Mechanisms

    • Key Aggregation via MuSig2 — MuSig2 extends BIP-340 to allow n parties each holding a private key to jointly produce a single BIP-340 Schnorr signature over an aggregate public key, without any single party learning the others’ keys. The result is a valid BIP-340 signature indistinguishable from a single-signer output.
    • Script-less Scripts — The linearity of Schnorr Signature enables “adaptor signatures” where one party can only complete a signature after learning a secret. This is used in Point Time-Locked Contract for atomic swaps and improved payment routing in the Lightning Network without on-chain script exposure.
    • Taproot Key-Path Spend — When a Taproot output is spent via the key path (BIP-341), the spending transaction includes a BIP-340 signature. This makes the simplest Taproot spend look identical on-chain to a legacy P2WPKH spend.
    • Half-Aggregation — Research subsequent to BIP-340 (not yet deployed) proposes half-aggregation of independent Schnorr signatures in a block, which could halve aggregate signature data per transaction. This depends on BIP-340 as a foundation.

    Applications and Use Cases

    • Taproot Wallets — Hardware and software wallets implementing BIP-341 Taproot output types must implement BIP-340 signing and verification for key-path spends. All major Bitcoin wallets (Ledger, Trezor, Bitcoin Core, Sparrow) added BIP-340 support at or shortly after Taproot activation.
    • Multi-Party Custody — Institutional custody providers use MuSig2 over BIP-340 to implement 2-of-3 or 3-of-5 signing policies that appear as a single-signature spend on-chain, reducing fees and improving confidentiality.
    • Lightning Network PTLCs — Point Time-Locked Contract replace HTLCs in next-generation Lightning channel factories. PTLCs use BIP-340 adaptor signatures to bind payment preimages to signature completion, improving privacy by eliminating the correlation of payment hashes across hops.
    • Discreet Log Contracts (DLCs) — Discreet Log Contract schemes that settle based on oracle announcements use BIP-340 adaptor signatures to ensure only the correct oracle attestation unlocks the settlement signature.
    • Covenants Research — Proposed covenant opcodes (OP_CHECKSIGFROMSTACK, LNHANCE) build on BIP-340’s Schnorr infrastructure to enable complex spending conditions enforced without revealing policy on-chain.
    • Cross-Chain Atomic Swaps — Schnorr adaptor signatures enable trustless atomic swaps between Bitcoin and other secp256k1-based chains (e.g. Litecoin, Liquid) using a single on-chain output per side.
    • Threshold Signature Schemes (FROST) — FROST (Flexible Round-Optimised Schnorr Threshold) uses BIP-340 output format to produce t-of-n threshold signatures in two rounds, enabling distributed key ceremonies with no trusted dealer.

    Standards and Context

    • BIP-340 was merged into the Bitcoin Improvement Proposals repository and locked as a Final standard following Taproot’s activation at block height 709,632 in November 2021.
    • It is co-specified with BIP-341 (Taproot script output structure) and BIP-342 (Tapscript opcode semantics), and all three are collectively referred to as the Taproot Upgrade.
    • The specification references RFC 6979 for deterministic nonce generation practices, though it uses a tagged-hash variant rather than RFC 6979’s HMAC-DRBG construction.
    • The secp256k1 curve parameters used by BIP-340 are identical to those specified in the SEC 2 standard published by Certicom Research, ensuring compatibility with existing Bitcoin key material.
    • BIP-340 does not alter the consensus rules for pre-existing P2PKH, P2SH, P2WPKH, or P2WSH output types; ECDSA remains the signature algorithm for those output types.
    • The MuSig2 protocol that builds on BIP-340 is specified in a separate BIP (BIP-327), authored by Jonas Nick, Tim Ruffing, and Elliott Jin.
    • FROST threshold signatures over BIP-340 are specified in IETF RFC 9591 (published June 2024).
    • Implementations include: Bitcoin Core (libsecp256k1 library), libsecp256k1-zkp (for MuSig2/FROST), rust-secp256k1, and numerous language bindings.

    Security Considerations

    • Nonce Reuse — Reusing the same nonce k for two different messages reveals the private key; the deterministic nonce procedure specified in BIP-340 eliminates this risk if followed correctly.
    • Auxiliary Randomness — BIP-340 recommends supplying 32 bytes of fresh randomness as auxiliary input to the nonce function even though the scheme is deterministic; this protects against fault attacks (e.g. via voltage glitching on hardware signers) that could otherwise reveal the key.
    • Related-Key Attacks — X-only keys require care when deriving child keys via BIP-32 HD Wallets; implementations must handle the case where a derived child key’s y-coordinate is odd and negate accordingly.
    • Batch Verification — Batch verification is not safe in all contexts; a single forged signature in a batch will cause the entire batch to fail without identifying the offending entry, requiring fallback to individual verification.
    • Complexity vs ECDSA — While Schnorr is simpler mathematically, the Taproot ecosystem (BIP-340/341/342) introduces implementation complexity; errors in Taproot script path construction are a known source of fund loss.

    Current Landscape (2026)

    • Ecosystem effort in 2024-2026 has shifted from BIP-340’s ratification (Status: Final) to the higher-level protocols it enables: MuSig2 was standardised as BIP-327 (n-of-n key aggregation producing a single 64-byte Schnorr key-path spend), and FROST t-of-n threshold signing over secp256k1 was standardised in RFC 9591 (June 2024), with a BIP340-compatible signing draft (siv2r/bip-frost-signing, based on the FROST3/ROAST variant) and Blockstream’s ChillDKG distributed-key-generation draft still in progress.
    • Wallet support matured through 2025: Ledger became the first major hardware wallet to ship MuSig2 (Bitcoin app v2.4.0, April 2025), Nunchuk launched a MuSig2 Taproot multisig wallet in 2026 (beta), and Schnorr key-path signing is now standard across Bitcoin Core, Sparrow, Electrum, Wasabi, Coldcard, Trezor, BitBox02, Keystone, Jade and Passport.
    • FROST remains experimental on Bitcoin as of mid-2026: no production wallet has deployed it on mainnet, the signing BIP sits at roughly v0.3.5 and the DKG BIP is unfinished, though the Zcash Foundation’s frost-secp256k1-tr Rust crate provides BIP340/BIP341-compatible tooling.
    • Taproot (and hence Schnorr) usage has normalised: after a peak above 40% of transactions in early 2024 driven by Ordinals inscriptions and the Runes launch (23 April 2024), key-path/P2TR share settled to roughly 15-20% by early 2026, reflecting organic wallet adoption rather than inscription volume; around 12% of UTXOs use P2TR outputs as of July 2026.
    • Cross-input signature aggregation (CISA) - deliberately excluded from the original Taproot fork but enabled by Schnorr linearity - re-emerged as a live agenda item, with a Human Rights Foundation industry paper (March 2025) and a 2026 draft BIP for full aggregation of BIP340 signatures under discussion as a future soft fork.
    • Post-quantum concerns are now on the frontier: a 2025 paper analysed the security of Taproot commitments against quantum computers, since Schnorr over secp256k1 (like ECDSA) relies on the hardness of the discrete-log problem and would be broken by a sufficiently large quantum computer.
    • Open challenges as of 2026 include finalising the FROST/ChillDKG specifications and shipping audited threshold wallets, achieving consensus for CISA, deepening script-path and MuSig2 support (still available in only a handful of wallets), and charting a post-quantum migration path for key-path spends.

    References

    Provenance

    Graph View

    Backlinks