--- bip: 340 title: "Schnorr Signatures for secp256k1" status: Deployed type: Specification authors: ["Pieter Wuille","Jonas Nick","Tim Ruffing"] assigned: 2020-01-19 last_modified: 2025-10-22 topics: ["taproot","schnorr","signatures","privacy"] license: "BSD-2-Clause" url: https://bipexplorer.com/bip/340 source: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki --- # BIP 340: Schnorr Signatures for secp256k1 > **In plain English:** Defines a standard for Schnorr signatures, a simpler and more flexible signing method than the ECDSA scheme Bitcoin originally used, on the same elliptic curve. Schnorr signatures are compact (64 bytes) and allow several signers to combine their keys and signatures into one, enabling cheaper and more private multi-party transactions. ## Introduction ### Abstract This document proposes a standard for 64-byte Schnorr signatures over the elliptic curve _secp256k1_. ### Copyright This document is licensed under the 2-clause BSD license. ### Motivation Bitcoin has traditionally used [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) signatures over the [secp256k1 curve](https://www.secg.org/sec2-v2.pdf) with [SHA256](https://en.wikipedia.org/wiki/SHA-2) hashes for authenticating transactions. These are [standardized](https://www.secg.org/sec1-v2.pdf), but have a number of downsides compared to [Schnorr signatures](http://publikationen.ub.uni-frankfurt.de/opus4/files/4280/schnorr.pdf) over the same curve: - **Provable security**: Schnorr signatures are provably secure. In more detail, they are _strongly unforgeable under chosen message attack (SUF-CMA)_[1] [in the random oracle model assuming the hardness of the elliptic curve discrete logarithm problem (ECDLP)](https://www.di.ens.fr/~pointche/Documents/Papers/2000_joc.pdf) and [in the generic group model assuming variants of preimage and second preimage resistance of the used hash function](http://www.neven.org/papers/schnorr.pdf)[2]. In contrast, the [best known results for the provable security of ECDSA](https://nbn-resolving.de/urn:nbn:de:hbz:294-60803) rely on stronger assumptions. - **Non-malleability**: The SUF-CMA security of Schnorr signatures implies that they are non-malleable. On the other hand, ECDSA signatures are inherently malleable[3]; a third party without access to the secret key can alter an existing valid signature for a given public key and message into another signature that is valid for the same key and message. This issue is discussed in [BIP62](https://bipexplorer.com/bip/62) and [BIP146](https://bipexplorer.com/bip/146). - **Linearity**: Schnorr signatures provide a simple and efficient method that enables multiple collaborating parties to produce a signature that is valid for the sum of their public keys. This is the building block for various higher-level constructions that improve efficiency and privacy, such as multisignatures and others (see Applications below). For all these advantages, there are virtually no disadvantages, apart from not being standardized. This document seeks to change that. As we propose a new standard, a number of improvements not specific to Schnorr signatures can be made: - **Signature encoding**: Instead of using [DER](https://en.wikipedia.org/wiki/X.690#DER_encoding)\-encoding for signatures (which are variable size, and up to 72 bytes), we can use a simple fixed 64-byte format. - **Public key encoding**: Instead of using [''compressed''](https://www.secg.org/sec1-v2.pdf) 33-byte encodings of elliptic curve points which are common in Bitcoin today, public keys in this proposal are encoded as 32 bytes. - **Batch verification**: The specific formulation of ECDSA signatures that is standardized cannot be verified more efficiently in batch compared to individually, unless additional witness data is added. Changing the signature scheme offers an opportunity to address this. - **Completely specified**: To be safe for usage in consensus systems, the verification algorithm must be completely specified at the byte level. This guarantees that nobody can construct a signature that is valid to some verifiers but not all. This is traditionally not a requirement for digital signature schemes, and the lack of exact specification for the DER parsing of ECDSA signatures has caused problems for Bitcoin [in the past](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html), needing [BIP66](https://bipexplorer.com/bip/66) to address it. In this document we aim to meet this property by design. For batch verification, which is inherently non-deterministic as the verifier can choose their batches, this property implies that the outcome of verification may only differ from individual verifications with negligible probability, even to an attacker who intentionally tries to make batch- and non-batch verification differ. By reusing the same curve and hash function as Bitcoin uses for ECDSA, we are able to retain existing mechanisms for choosing secret and public keys, and we avoid introducing new assumptions about the security of elliptic curves and hash functions. ## Description We first build up the algebraic formulation of the signature scheme by going through the design choices. Afterwards, we specify the exact encodings and operations. ### Design **Schnorr signature variant** Elliptic Curve Schnorr signatures for message _m_ and public key _P_ generally involve a point _R_, integers _e_ and _s_ picked by the signer, and the base point _G_ which satisfy _e = hash(R || m)_ and _s⋅G = R + e⋅P_. Two formulations exist, depending on whether the signer reveals _e_ or _R_: 1. Signatures are pairs _(e, s)_ that satisfy _e = hash(s⋅G - e⋅P || m)_. This variant avoids minor complexity introduced by the encoding of the point _R_ in the signature (see paragraphs "Encoding R and public key point P" and "Implicit Y coordinates" further below in this subsection). Moreover, revealing _e_ instead of _R_ allows for potentially shorter signatures: Whereas an encoding of _R_ inherently needs about 32 bytes, the hash _e_ can be tuned to be shorter than 32 bytes, and [a short hash of only 16 bytes suffices to provide SUF-CMA security at the target security level of 128 bits](http://www.neven.org/papers/schnorr.pdf). However, a major drawback of this optimization is that finding collisions in a short hash function is easy. This complicates the implementation of secure signing protocols in scenarios in which a group of mutually distrusting signers work together to produce a single joint signature (see Applications below). In these scenarios, which are not captured by the SUF-CMA model due its assumption of a single honest signer, a promising attack strategy for malicious co-signers is to find a collision in the hash function in order to obtain a valid signature on a message that an honest co-signer did not intend to sign. 1. Signatures are pairs _(R, s)_ that satisfy _s⋅G = R + hash(R || m)⋅P_. This supports batch verification, as there are no elliptic curve operations inside the hashes. Batch verification enables significant speedups.[4] Since we would like to avoid the fragility that comes with short hashes, the _e_ variant does not provide significant advantages. We choose the _R_\-option, which supports batch verification. **Key prefixing** Using the verification rule above directly makes Schnorr signatures vulnerable to "related-key attacks" in which a third party can convert a signature _(R, s)_ for public key _P_ into a signature _(R, s + a⋅hash(R || m))_ for public key _P + a⋅G_ and the same message _m_, for any given additive tweak _a_ to the signing key. This would render signatures insecure when keys are generated using [BIP32's unhardened derivation](https://bipexplorer.com/bip/32#public-parent-key-public-child-key) and other methods that rely on additive tweaks to existing keys such as Taproot. To protect against these attacks, we choose _key prefixed_[5] Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to _s⋅G = R + hash(R || P || m)⋅P_. [It can be shown](https://eprint.iacr.org/2015/1135.pdf) that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving multiparty signing protocols (such as MuSig, MuSig2, and FROST) secure (see Applications below). We note that key prefixing is not strictly necessary for transaction signatures as used in Bitcoin currently, because signed transactions indirectly commit to the public keys already, i.e., _m_ contains a commitment to _pk_. However, this indirect commitment should not be relied upon because it may change with proposals such as SIGHASH\_NOINPUT ([BIP118](https://bipexplorer.com/bip/118)), and would render the signature scheme unsuitable for other purposes than signing transactions, e.g., [signing ordinary messages](https://bitcoin.org/en/developer-reference#signmessage). **Encoding R and public key point P** There exist several possibilities for encoding elliptic curve points: 1. Encoding the full X and Y coordinates of _P_ and _R_, resulting in a 64-byte public key and a 96-byte signature. 1. Encoding the full X coordinate and one bit of the Y coordinate to determine one of the two possible Y coordinates. This would result in 33-byte public keys and 65-byte signatures. 1. Encoding only the X coordinate, resulting in 32-byte public keys and 64-byte signatures. Using the first option would be slightly more efficient for verification (around 10%), but we prioritize compactness, and therefore choose option 3. **Implicit Y coordinates** In order to support efficient verification and batch verification, the Y coordinate of _P_ and of _R_ cannot be ambiguous (every valid X coordinate has two possible Y coordinates). We have a choice between several options for symmetry breaking: 1. Implicitly choosing the Y coordinate that is in the lower half. 1. Implicitly choosing the Y coordinate that is even[6]. 1. Implicitly choosing the Y coordinate that is a quadratic residue (i.e. has a square root modulo _p_). The second option offers the greatest compatibility with existing key generation systems, where the standard 33-byte compressed public key format consists of a byte indicating the oddness of the Y coordinate, plus the full X coordinate. To avoid gratuitous incompatibilities, we pick that option for _P_, and thus our X-only public keys become equivalent to a compressed public key that is the X-only key prefixed by the byte 0x02. For consistency, the same is done for _R_[7]. Despite halving the size of the set of valid public keys, implicit Y coordinates are not a reduction in security. Informally, if a fast algorithm existed to compute the discrete logarithm of an X-only public key, then it could also be used to compute the discrete logarithm of a full public key: apply it to the X coordinate, and then optionally negate the result. This shows that breaking an X-only public key can be at most a small constant term faster than breaking a full one.[8]. **Tagged Hashes** Cryptographic hash functions are used for multiple purposes in the specification below and in Bitcoin in general. To make sure hashes used in one context can't be reinterpreted in another one, hash functions can be tweaked with a context-dependent tag name, in such a way that collisions across contexts can be assumed to be infeasible. Such collisions obviously can not be ruled out completely, but only for schemes using tagging with a unique name. As for other schemes collisions are at least less likely with tagging than without. For example, without tagged hashing a BIP340 signature could also be valid for a signature scheme where the only difference is that the arguments to the hash function are reordered. Worse, if the BIP340 nonce derivation function was copied or independently created, then the nonce could be accidentally reused in the other scheme leaking the secret key. This proposal suggests to include the tag by prefixing the hashed data with _SHA256(tag) || SHA256(tag)_. Because this is a 64-byte long context-specific constant and the _SHA256_ block size is also 64 bytes, optimized implementations are possible (identical to SHA256 itself, but with a modified initial state). Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization. In general, tags can be arbitrary byte arrays, but are suggested to be textual descriptions in UTF-8 encoding. **Final scheme** As a result, our final scheme ends up using public key _pk_ which is the X coordinate of a point _P_ on the curve whose Y coordinate is even and signatures _(r,s)_ where _r_ is the X coordinate of a point _R_ whose Y coordinate is even. The signature satisfies _s⋅G = R + tagged\_hash(r || pk || m)⋅P_. ### Specification The following conventions are used, with constants as defined for [secp256k1](https://www.secg.org/sec2-v2.pdf). We note that adapting this specification to other elliptic curves is not straightforward and can result in an insecure scheme[9]. - Lowercase variables represent integers or byte arrays. - The constant _p_ refers to the field size, _0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F_. - The constant _n_ refers to the curve order, _0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141_. - Uppercase variables refer to points on the curve with equation _y2 = x3 + 7_ over the integers modulo _p_. - _is\_infinite(P)_ returns whether or not _P_ is the point at infinity. - _x(P)_ and _y(P)_ are integers in the range _0..p-1_ and refer to the X and Y coordinates of a point _P_ (assuming it is not infinity). - The constant _G_ refers to the base point, for which _x(G) = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798_ and _y(G) = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8_. - Addition of points refers to the usual [elliptic curve group operation](https://en.wikipedia.org/wiki/Elliptic_curve#The_group_law). - [Multiplication (⋅) of an integer and a point](https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication) refers to the repeated application of the group operation. - Functions and operations: - _||_ refers to byte array concatenation. - The function _x\[i:j\]_, where _x_ is a byte array and _i, j ≥ 0_, returns a _(j - i)_\-byte array with a copy of the _i_\-th byte (inclusive) to the _j_\-th byte (exclusive) of _x_. - The function _bytes(x)_, where _x_ is an integer, returns the 32-byte encoding of _x_, most significant byte first. - The function _bytes(P)_, where _P_ is a point, returns _bytes(x(P))_. - The function _int(x)_, where _x_ is a 32-byte array, returns the 256-bit unsigned integer whose most significant byte first encoding is _x_. - The function _has\_even\_y(P)_, where _P_ is a point for which _not is\_infinite(P)_, returns _y(P) mod 2 = 0_. - The function _lift\_x(x)_, where _x_ is a 256-bit unsigned integer, returns the point _P_ for which _x(P) = x_ Given a candidate X coordinate _x_ in the range _0..p-1_, there exist either exactly two or exactly zero valid Y coordinates. If no valid Y coordinate exists, then _x_ is not a valid X coordinate either, i.e., no point _P_ exists for which _x(P) = x_. The valid Y coordinates for a given candidate _x_ are the square roots of _c = x3 + 7 mod p_ and they can be computed as _y = ±c(p+1)/4 mod p_ (see [Quadratic residue](https://en.wikipedia.org/wiki/Quadratic_residue#Prime_or_prime_power_modulus)) if they exist, which can be checked by squaring and comparing with _c_. and _has\_even\_y(P)_, or fails if _x_ is greater than _p-1_ or no such point exists. The function _lift\_x(x)_ is equivalent to the following pseudocode: - - - Fail if _x ≥ p_. - Let _c = x3 + 7 mod p_. - Let _y = c(p+1)/4 mod p_. - Fail if _c ≠ y2 mod p_. - Return the unique point _P_ such that _x(P) = x_ and _y(P) = y_ if _y mod 2 = 0_ or _y(P) = p-y_ otherwise. - The function _hashname(x)_ where _x_ is a byte array returns the 32-byte hash _SHA256(SHA256(tag) || SHA256(tag) || x)_, where _tag_ is the UTF-8 encoding of _name_. #### Public Key Generation Input: - The secret key _sk_: a 32-byte array, freshly generated uniformly at random The algorithm _PubKey(sk)_ is defined as: - Let _d' = int(sk)_. - Fail if _d' = 0_ or _d' ≥ n_. - Return _bytes(d'⋅G)_. Note that we use a very different public key format (32 bytes) than the ones used by existing systems (which typically use elliptic curve points as public keys, or 33-byte or 65-byte encodings of them). A side effect is that _PubKey(sk) = PubKey(bytes(n - int(sk))_, so every public key has two corresponding secret keys. #### Public Key Conversion As an alternative to generating keys randomly, it is also possible and safe to repurpose existing key generation algorithms for ECDSA in a compatible way. The secret keys constructed by such an algorithm can be used as _sk_ directly. The public keys constructed by such an algorithm (assuming they use the 33-byte compressed encoding) need to be converted by dropping the first byte. Specifically, [BIP32](https://bipexplorer.com/bip/32) and schemes built on top of it remain usable. #### Default Signing Input: - The secret key _sk_: a 32-byte array - The message _m_: a byte array - Auxiliary random data _a_: a 32-byte array The algorithm _Sign(sk, m)_ is defined as: - Let _d' = int(sk)_ - Fail if _d' = 0_ or _d' ≥ n_ - Let _P = d'⋅G_ - Let _d = d'_ if _has\_even\_y(P)_, otherwise let _d = n - d'_ . - Let _t_ be the byte-wise xor of _bytes(d)_ and _hashBIP0340/aux(a)_[10]. - Let _rand = hashBIP0340/nonce(t || bytes(P) || m)_[11]. - Let _k' = int(rand) mod n_[12]. - Fail if _k' = 0_. - Let _R = k'⋅G_. - Let _k = k'_ if _has\_even\_y(R)_, otherwise let _k = n - k'_ . - Let _e = int(hashBIP0340/challenge(bytes(R) || bytes(P) || m)) mod n_. - Let _sig = bytes(R) || bytes((k + ed) mod n)_. - If _Verify(bytes(P), m, sig)_ (see below) returns failure, abort[13]. - Return the signature _sig_. The auxiliary random data should be set to fresh randomness generated at signing time, resulting in what is called a _synthetic nonce_. Using 32 bytes of randomness is optimal. If obtaining randomness is expensive, 16 random bytes can be padded with 16 null bytes to obtain a 32-byte array. If randomness is not available at all at signing time, a simple counter wide enough to not repeat in practice (e.g., 64 bits or wider) and padded with null bytes to a 32 byte-array can be used, or even the constant array with 32 null bytes. Using any non-repeating value increases protection against [fault injection attacks](https://moderncrypto.org/mail-archive/curves/2017/000925.html). Using unpredictable randomness additionally increases protection against other side-channel attacks, and is **recommended whenever available**. Note that while this means the resulting nonce is not deterministic, the randomness is only supplemental to security. The normal security properties (excluding side-channel attacks) do not depend on the quality of the signing-time RNG. #### Alternative Signing It should be noted that various alternative signing algorithms can be used to produce equally valid signatures. The 32-byte _rand_ value may be generated in other ways, producing a different but still valid signature (in other words, this is not a _unique_ signature scheme). **No matter which method is used to generate the _rand_ value, the value must be a fresh uniformly random 32-byte string which is not even partially predictable for the attacker.** For nonces without randomness, this implies that the same inputs must not be presented in another context. This can be most reliably accomplished by not reusing the same private key across different signing schemes. For example, if the _rand_ value was computed as per RFC6979 and the same secret key is used in deterministic ECDSA with RFC6979, the signatures can leak the secret key through nonce reuse. **Nonce exfiltration protection** It is possible to strengthen the nonce generation algorithm using a second device. In this case, the second device contributes randomness which the actual signer provably incorporates into its nonce. This prevents certain attacks where the signer's device is compromised and intentionally tries to leak the secret key through its nonce selection. **Multisignatures** This signature scheme is compatible with various types of multisignature and threshold schemes such as [MuSig2](https://eprint.iacr.org/2020/1261.pdf), where a single public key requires holders of multiple secret keys to participate in signing (see Applications below). **It is important to note that multisignature signing schemes in general are insecure with the _rand_ generation from the default signing algorithm above (or any other deterministic method).** **Precomputed public key data** For many uses, the compressed 33-byte encoding of the public key corresponding to the secret key may already be known, making it easy to evaluate _has\_even\_y(P)_ and _bytes(P)_. As such, having signers supply this directly may be more efficient than recalculating the public key from the secret key. However, if this optimization is used and additionally the signature verification at the end of the signing algorithm is dropped for increased efficiency, signers must ensure the public key is correctly calculated and not taken from untrusted sources. #### Verification Input: - The public key _pk_: a 32-byte array - The message _m_: a byte array - A signature _sig_: a 64-byte array The algorithm _Verify(pk, m, sig)_ is defined as: - Let _P = lift\_x(int(pk))_; fail if that fails. - Let _r = int(sig\[0:32\])_; fail if _r ≥ p_. - Let _s = int(sig\[32:64\])_; fail if _s ≥ n_. - Let _e = int(hashBIP0340/challenge(bytes(r) || bytes(P) || m)) mod n_. - Let _R = s⋅G - e⋅P_. - Fail if _is\_infinite(R)_. - Fail if _not has\_even\_y(R)_. - Fail if _x(R) ≠ r_. - Return success iff no failure occurred before reaching this point. For every valid secret key _sk_ and message _m_, _Verify(PubKey(sk),m,Sign(sk,m))_ will succeed. Note that the correctness of verification relies on the fact that _lift\_x_ always returns a point with an even Y coordinate. A hypothetical verification algorithm that treats points as public keys, and takes the point _P_ directly as input would fail any time a point with odd Y is used. While it is possible to correct for this by negating points with odd Y coordinate before further processing, this would result in a scheme where every (message, signature) pair is valid for two public keys (a type of malleability that exists for ECDSA as well, but we don't wish to retain). We avoid these problems by treating just the X coordinate as public key. #### Batch Verification Input: - The number _u_ of signatures - The public keys _pk1..u_: _u_ 32-byte arrays - The messages _m1..u_: _u_ byte arrays - The signatures _sig1..u_: _u_ 64-byte arrays The algorithm _BatchVerify(pk1..u, m1..u, sig1..u)_ is defined as: - Generate _u-1_ random integers _a2...u_ in the range _1...n-1_. They are generated deterministically using a [CSPRNG](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator) seeded by a cryptographic hash of all inputs of the algorithm, i.e. _seed = seed\_hash(pk1..pku || m1..mu || sig1..sigu )_. A safe choice is to instantiate _seed\_hash_ with SHA256 and use [ChaCha20](https://tools.ietf.org/html/rfc8439) with key _seed_ as a CSPRNG to generate 256-bit integers, skipping integers not in the range _1...n-1_. - For _i = 1 .. u_: - Let _Pi = lift\_x(int(pki))_; fail if it fails. - Let _ri = int(sigi\[0:32\])_; fail if _ri ≥ p_. - Let _si = int(sigi\[32:64\])_; fail if _si ≥ n_. - Let _ei = int(hashBIP0340/challenge(bytes(ri) || bytes(Pi) || mi)) mod n_. - Let _Ri = lift\_x(ri)_; fail if _lift\_x(ri)_ fails. - Fail if _(s1 + a2s2 + ... + ausu)⋅G ≠ R1 + a2⋅R2 + ... + au⋅Ru + e1⋅P1 + (a2e2)⋅P2 + ... + (aueu)⋅Pu_. - Return success iff no failure occurred before reaching this point. If all individual signatures are valid (i.e., _Verify_ would return success for them), _BatchVerify_ will always return success. If at least one signature is invalid, _BatchVerify_ will return success with at most a negligible probability. ### Usage Considerations #### Messages of Arbitrary Size The signature scheme specified in this BIP accepts byte strings of arbitrary size as input messages.[14] It is understood that implementations may reject messages which are too large in their environment or application context, e.g., messages which exceed predefined buffers or would otherwise cause resource exhaustion. Earlier revisions of this BIP required messages to be exactly 32 bytes. This restriction puts a burden on callers who typically need to perform pre-hashing of the actual input message by feeding it through SHA256 (or another collision-resistant cryptographic hash function) to create a 32-byte digest which can be passed to signing or verification (as for example done in [BIP341](https://bipexplorer.com/bip/341).) Since pre-hashing may not always be desirable, e.g., when actual messages are shorter than 32 bytes,[15] the restriction to 32-byte messages has been lifted. We note that pre-hashing is recommended for performance reasons in applications that deal with large messages. If large messages are not pre-hashed, the algorithms of the signature scheme will perform more hashing internally. In particular, the signing algorithm needs two sequential hashing passes over the message, which means that the full message must necessarily be kept in memory during signing, and large messages entail a runtime penalty.[16] #### Domain Separation It is good cryptographic practice to use a key pair only for a single purpose. Nevertheless, there may be situations in which it may be desirable to use the same key pair in multiple contexts, i.e., to sign different types of messages within the same application or even messages in entirely different applications (e.g., a secret key may be used to sign Bitcoin transactions as well plain text messages). As a consequence, applications should ensure that a signed application message intended for one context is never deemed valid in a different context (e.g., a signed plain text message should never be misinterpreted as a signed Bitcoin transaction, because this could cause unintended loss of funds). This is called "domain separation" and it is typically realized by partitioning the message space. Even if key pairs are intended to be used only within a single context, domain separation is a good idea because it makes it easy to add more contexts later. As a best practice, we recommend applications to use exactly one of the following methods to pre-process application messages before passing it to the signature scheme: - Either, pre-hash the application message using _hashname_, where _name_ identifies the context uniquely (e.g., "foo-app/signed-bar"), - or prefix the actual message with a 33-byte string that identifies the context uniquely (e.g., the UTF-8 encoding of "foo-app/signed-bar", padded with null bytes to 33 bytes). As the two pre-processing methods yield different message sizes (32 bytes vs. at least 33 bytes), there is no risk of collision between them. ## Applications There are several interesting applications beyond simple signatures. While recent academic papers claim that they are also possible with ECDSA, consensus support for Schnorr signature verification would significantly simplify the constructions. ### Multisignatures and Threshold Signatures By means of an interactive scheme such as [MuSig2](https://eprint.iacr.org/2020/1261.pdf) ([BIP327](https://bipexplorer.com/bip/327)), participants can aggregate their public keys into a single public key which they can jointly sign for. This allows _n_\-of-_n_ multisignatures which, from a verifier's perspective, are no different from ordinary signatures, giving improved privacy and efficiency versus _CHECKMULTISIG_ or other means. Moreover, Schnorr signatures are compatible with [distributed key generation](https://en.wikipedia.org/wiki/Distributed_key_generation), which enables interactive threshold signatures schemes, e.g., the schemes by [Stinson and Strobl (2001)](http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps), by [Gennaro, Jarecki, Krawczyk, and Rabin (2007)](https://link.springer.com/content/pdf/10.1007/s00145-006-0347-3.pdf), or the [FROST](https://eprint.iacr.org/2020/852.pdf) scheme including its variants such as [FROST3](https://eprint.iacr.org/2023/899.pdf). These protocols make it possible to realize _k_\-of-_n_ threshold signatures, which ensure that any subset of size _k_ of the set of _n_ signers can sign but no subset of size less than _k_ can produce a valid Schnorr signature. ### Adaptor Signatures [Adaptor signatures](https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf) can be produced by a signer by offsetting his public nonce _R_ with a known point _T = t⋅G_, but not offsetting the signature's _s_ value. A correct signature (or partial signature, as individual signers' contributions to a multisignature are called) on the same message with same nonce will then be equal to the adaptor signature offset by _t_, meaning that learning _t_ is equivalent to learning a correct signature. This can be used to enable atomic swaps or even [general payment channels](https://eprint.iacr.org/2018/472) in which the atomicity of disjoint transactions is ensured using the signatures themselves, rather than Bitcoin script support. The resulting transactions will appear to verifiers to be no different from ordinary single-signer transactions, except perhaps for the inclusion of locktime refund logic. Adaptor signatures, beyond the efficiency and privacy benefits of encoding script semantics into constant-sized signatures, have additional benefits over traditional hash-based payment channels. Specifically, the secret values _t_ may be reblinded between hops, allowing long chains of transactions to be made atomic while even the participants cannot identify which transactions are part of the chain. Also, because the secret values are chosen at signing time, rather than key generation time, existing outputs may be repurposed for different applications without recourse to the blockchain, even multiple times. ### Blind Signatures A blind signature protocol is an interactive protocol that enables a signer to sign a message at the behest of another party without learning any information about the signed message or the signature. Schnorr signatures admit a very [simple blind signature scheme](http://publikationen.ub.uni-frankfurt.de/files/4292/schnorr.blind_sigs_attack.2001.pdf) which is however insecure because it's vulnerable to [Wagner's attack](https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf). Known mitigations are to let the signer abort a signing session with a certain probability, which can be [proven secure under non-standard cryptographic assumptions](https://eprint.iacr.org/2019/877), or [to use zero-knowledge proofs](https://eprint.iacr.org/2022/1676.pdf). Blind Schnorr signatures could for example be used in [Partially Blind Atomic Swaps](https://github.com/ElementsProject/scriptless-scripts/blob/master/md/partially-blind-swap.md), a construction to enable transferring of coins, mediated by an untrusted escrow agent, without connecting the transactors in the public blockchain transaction graph. ## Test Vectors and Reference Code For development and testing purposes, we provide a [collection of test vectors in CSV format](https://github.com/bitcoin/bips/blob/master/bip-0340/test-vectors.csv), a naive, highly inefficient, and non-constant time [pure Python 3.7 reference implementation of the signing and verification algorithm](https://github.com/bitcoin/bips/blob/master/bip-0340/reference.py) as well as the [script used to generate the test vectors](https://github.com/bitcoin/bips/blob/master/bip-0340/test-vectors.py) under the BSD-2-Clause License, or the MIT License, or CC0 1.0, at your choice. The reference implementation is for demonstration purposes only and not to be used in production environments. ## Changelog To help implementers understand updates to this BIP, we keep a list of substantial changes. - 2022-08: Fix function signature of lift\_x in reference code - 2023-04: Allow messages of arbitrary size - 2024-05: Update "Applications" section with more recent references - 2025-04: Change license of test vectors and code ## Footnotes 1. Informally, this means that without knowledge of the secret key but given valid signatures of arbitrary messages, it is not possible to come up with further valid signatures. 2. A detailed security proof in the random oracle model, which essentially restates [the original security proof by Pointcheval and Stern](https://www.di.ens.fr/~pointche/Documents/Papers/2000_joc.pdf) more explicitly, can be found in [a paper by Kiltz, Masny and Pan](https://eprint.iacr.org/2016/191). All these security proofs assume a variant of Schnorr signatures that use _(e,s)_ instead of _(R,s)_ (see Design above). Since we use a unique encoding of _R_, there is an efficiently computable bijection that maps _(R,s)_ to _(e,s)_, which allows to convert a successful SUF-CMA attacker for the _(e,s)_ variant to a successful SUF-CMA attacker for the _(R,s)_ variant (and vice-versa). Furthermore, the proofs consider a variant of Schnorr signatures without key prefixing (see Design above), but it can be verified that the proofs are also correct for the variant with key prefixing. As a result, all the aforementioned security proofs apply to the variant of Schnorr signatures proposed in this document. 3. If _(r,s)_ is a valid ECDSA signature for a given message and key, then _(r,n-s)_ is also valid for the same message and key. If ECDSA is restricted to only permit one of the two variants (as Bitcoin does through a policy rule on the network), it can be [proven](https://nbn-resolving.de/urn:nbn:de:hbz:294-60803) non-malleable under stronger than usual assumptions. 4. The speedup that results from batch verification can be demonstrated with the cryptography library [libsecp256k1](https://github.com/jonasnick/secp256k1/blob/schnorrsig-batch-verify/doc/speedup-batch.md). 5. A limitation of committing to the public key (rather than to a short hash of it, or not at all) is that it removes the ability for public key recovery or verifying signatures against a short public key hash. These constructions are generally incompatible with batch verification. 6. Since _p_ is odd, negation modulo _p_ will map even numbers to odd numbers and the other way around. This means that for a valid X coordinate, one of the corresponding Y coordinates will be even, and the other will be odd. 7. An earlier version of this draft used the third option instead, based on a belief that this would in general trade signing efficiency for verification efficiency. When using Jacobian coordinates, a common optimization in ECC implementations, it is possible to determine if a Y coordinate is a quadratic residue by computing the Legendre symbol, without converting to affine coordinates first (which needs a modular inversion). As modular inverses and Legendre symbols have similar [performance](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018081.html) in practice, this trade-off is not worth it. 8. This can be formalized by a simple reduction that reduces an attack on Schnorr signatures with implicit Y coordinates to an attack to Schnorr signatures with explicit Y coordinates. The reduction works by reencoding public keys and negating the result of the hash function, which is modeled as random oracle, whenever the challenge public key has an explicit Y coordinate that is odd. A proof sketch can be found [here](https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7). 9. Among other pitfalls, using the specification with a curve whose order is not close to the size of the range of the nonce derivation function is insecure. 10. The auxiliary random data is hashed (with a unique tag) as a precaution against situations where the randomness may be correlated with the private key itself. It is xored with the private key (rather than combined with it in a hash) to reduce the number of operations exposed to the actual secret key. 11. Including the [public key as input to the nonce hash](https://moderncrypto.org/mail-archive/curves/2020/001012.html) helps ensure the robustness of the signing algorithm by preventing leakage of the secret key if the calculation of the public key _P_ is performed incorrectly or maliciously, for example if it is left to the caller for performance reasons. 12. Note that in general, taking a uniformly random 256-bit integer modulo the curve order will produce an unacceptably biased result. However, for the secp256k1 curve, the order is sufficiently close to _2256_ that this bias is not observable (_1 - n / 2256_ is around _1.27 \* 2\-128_). 13. Verifying the signature before leaving the signer prevents random or attacker provoked computation errors. This prevents publishing invalid signatures which may leak information about the secret key. It is recommended, but can be omitted if the computation cost is prohibitive. 14. In theory, the message size is restricted due to the fact that SHA256 accepts byte strings only up to size of 2^61-1 bytes. 15. Another reason to omit pre-hashing is to protect against certain types of cryptanalytic advances against the hash function used for pre-hashing: If pre-hashing is used, an attacker that can find collisions in the pre-hashing function can necessarily forge signatures under chosen-message attacks. If pre-hashing is not used, an attacker that can find collisions in SHA256 (as used inside the signature scheme) may not be able to forge signatures. However, this seeming advantage is mostly irrelevant in the context of Bitcoin, which already relies on collision resistance of SHA256 in other places, e.g., for transaction hashes. 16. Typically, messages of 56 bytes or longer enjoy a performance benefit from pre-hashing, assuming the speed of SHA256 inside the signing algorithm matches that of the pre-hashing done by the calling application. ## Acknowledgements This document is the result of many discussions around Schnorr based signatures over the years, and had input from Johnson Lau, Greg Maxwell, Andrew Poelstra, Rusty Russell, and Anthony Towns. The authors further wish to thank all those who provided valuable feedback and reviews, including the participants of the [structured reviews](https://github.com/ajtowns/taproot-review).