You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
131 lines
9.8 KiB
131 lines
9.8 KiB
[[schnorr]]
|
|
=== Schnorr Signatures
|
|
|
|
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
|
|
|
|
A _Schnorr signature_ is a digital signature scheme for elliptic curves named after the inventor of the algorithm Claus Schnorr. Schnorr signatures were proposed in 1989 and subsequently held under patent by Claus Schnorr until 2008, which coincided with the year of Bitcoin's invention.
|
|
|
|
Bitcoin was originally designed to use the Elliptic Curve Digital Signature Algorithm (ECDSA) algorithm. Schnorr signatures are an _alternative_ signature scheme to ECDSA. Schnorr signatures were introduced in Bitcoin in 2021, as part of a _soft fork_ upgrade package called "Taproot". The Bitcoin implementation of Schnorr signatures is specified in BIP-340 found at https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki (see <<BIP-340>>).
|
|
|
|
Schnorr signatures offer several advantages compared to ECDSA signatures, including _provable security_, _key aggregation_, _batch verification_, and _space efficiency_. These advantages lead to increased privacy and capacity for Bitcoin, when Schnorr signatures are used instead of ECDSA signatures.
|
|
|
|
[[why_ecdsa_over_schnorr]]
|
|
.Why did Satoshi use ECDSA instead of Schnorr?
|
|
****
|
|
If Schnorr signatures are superior to ECDSA signatures, why did Satoshi use ECDSA?
|
|
|
|
In 2008, the patent on Schnorr signatures expired, meaning that Satoshi could have used Schnorr signatures in Bitcoin instead of ECDSA. Given the many advantages, we must wonder why Satoshi didn't use Schnorr signatures.
|
|
|
|
While we don't have a definitive answer, the commonly accepted reasoning is that in 2008 ECDSA signatures were standardized, well tested and implemented in several broadly used cryptographic libraries (e.g. OpenSSL). In contrast, Schnorr signatures were not standardized or as well studied, probably because the patent prevented them from being broadly used without paying for a license.
|
|
|
|
BIP-340 is the culmination of a multi-year research, standardization, and development effort to bring Schnorr signatures to Bitcoin.
|
|
****
|
|
|
|
==== Bitcoin's implementation of Schnorr signatures
|
|
|
|
Schnorr signatures in Bitcoin are implemented according to BIP-340, which outlines the specific design choices and adaptations made to the Schnorr signature algorithm. Remember that a signature scheme, such as ECDSA or Schnorr, is simply a pair of equations that we can use to respectively produce and verify a signature. For both ECDSA and Schnorr signatures, the corresponding equations can be applied to any elliptic curve, relying on the discrete logarithm problem for their security properties.
|
|
|
|
In Bitcoin, Schnorr signatures are applied to the secp256k1 elliptic curve. This is the same elliptic curve chosen by Satoshi that is used for ECDSA signatures. The difference is in the equations used to calculate and verify the signatures. When adapting Schnorr signatures for use in Bitcoin, the developers had to make several design choices that are specific to the security requirements of a decentralized cryptocurrency. In doing so, the Bitcoin developers have _adapted_ and _standardized_ the Schnorr signature algorithm and the encoding of the signatures. When we describe Schnorr signatures in this book, we are therefore describing the specific implentation of Schnorr signatures for Bitcoin, rather than the Schnorr signature scheme in general.
|
|
|
|
The BIP-340 document contains more than simply the final implementation of Bitcoin's Schnorr signatures: it describes the various design decisions and the rationale for the choices that were made. While we won't repeat those explanations here, we urge you to read BIP-340 for yourself, so that you may better understand the process and reasoning behind the specification.
|
|
|
|
[[schnorr_sigs_illustrated]]
|
|
==== Schnorr signatures illustrated
|
|
|
|
One of the best ways to understand Schnorr signatures, is to visualize the signing and verification steps.
|
|
|
|
In <<schnorr_sigs_illustrated_diag>>footnote:[The Schnorr signature illustration is sourced from Stepan Snigirev's article "How Schnorr Signatures May Improve Bitcoin" (https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744)] below, you can see the Schnorr signature algorithm, visualized. In the diagram, the red arrows represent operations that the signer performs to create a Schnorr signature, whereas blue arrows represent operations that anyone else can perform to verify that signature. The "signature" is simply the values (R, s), which the signer embeds in the signed transaction. Once anyone receives the transaction with the signature values (R, s), they can verify that this is a valid signature for message +m+, signed by the signer with public key +P+. The verification process is highlighted by the blue arrows. The link between the signature produced by the signer and the verification is the
|
|
|
|
The black curved line represents the +secp256k1+ elliptic curve, Bitcoin's default curve for key operations. The curve has a static, pre-defined starting point, called the _generator point_, shown on the curve as point +G+. Public keys are derived by scalar multiplication of a private key and the generator point.
|
|
|
|
For example, the public key of the transaction signer +P+ is computed by the multiplication of their private key +pk+ with the generator point +G+. You can see this operation highlighted as a red arrow "from" point +G+ to point +P+, with the formula +P = pk x G+ above the red arrow.
|
|
|
|
|
|
|
|
|
|
[[schnorr_sigs_illustrated_diag]]
|
|
.Schnorr signatures illustrated
|
|
image::images/schnorr_signatures.png["Schnorr signatures illustrated"]
|
|
|
|
==== Creting a Schnorr signature
|
|
|
|
The first part of a signature scheme is the formula used to create the digital signature, which is shown in <<schnorr_signing_formula>>:
|
|
|
|
[[schnorr_signing_formula]]
|
|
.Bitcoin's Schnorr signing formula
|
|
latexmath:[\(S = R + hash(R || A || m) ⋅ A\)]
|
|
|
|
Let's work through this formula step-by-step, explaining the various components as they are built from the perspective of the software that is signing a specific Bitcoin transaction.
|
|
|
|
[TIP]
|
|
====
|
|
Throughout this book, we use lower-case letters to represent private keys (eg. +a+ is Alice's private key) and the corresponding upper case letter to denote the public key (eg. +A+ is Alice's public key). Upper-case letters more generally represent points on the elliptic curve, with +G+ being the special predefined generator point of the curve.
|
|
====
|
|
|
|
===== The wallet owner's private key (a)
|
|
|
|
First of all, the purpose of Bitcoin digital signatures is to prove ownership and allow spending of bitcoin in a transaction. Alice, the owner of the bitcoin being spent, has a private key +a+, which she has kept secret. Alice has derived a corresponding public key +A+, such that latexmath:[\(A = a⋅G\)]. As a reminder, +G+ is a known and fixed point on the elliptic curve called the _generator point_, used as the starting point for elliptic curve multiplication and public key derivation (see <<public_key_derivation>>).
|
|
|
|
===== The ephemeral random value +r+
|
|
|
|
The signing software will randomly generate one more integer (also known as the _emphemeral key_ ) +r+ and corresponding point +R+ such that:
|
|
|
|
latexmath:[\(R = r⋅G\)]
|
|
|
|
As in ECDSA signatures, it is *essential* to the security of the Schnorr signature scheme that +r+ is indeed random and used only once. Repeating values of +r+ with different messages or signing keys may allow an attacker to guess the signer's private key, defeating the security of the scheme.
|
|
|
|
////
|
|
TODO
|
|
As a reminder, wallet developers decide how their signing software will work and it is up to them to ensure there are no repeating +r+ values.
|
|
////
|
|
|
|
===== The Bitcoin transaction (message) +m+
|
|
|
|
In cryptography, the thing we are signing is called the "message". In Bitcoin, the message is the serialized Bitcoin transaction. Therefore, in the signing formula we represent the serialized Bitcoin transaction with the letter +m+, from the word "message".
|
|
|
|
===== The prefixed hash of the message +m+
|
|
The signing software will now calculate a SHA256 hash of the message +m+, prefixed by +R+ and +A+, as follows:
|
|
|
|
latexmath:[\(hash( R || A || m )\)]
|
|
|
|
In Bitcoin's implementation of Schnorr signatures, the message is prefixed by +R+ and +A+ in the hash formula so as to _bind_ the signed message to those public keys, preventing a class of attacks called "related key attacks".
|
|
|
|
////
|
|
TODO
|
|
To learn more about "related key attacks" see:
|
|
////
|
|
|
|
===== Calculating the signature value +s+
|
|
|
|
Finally, Alice's wallet calculates a value for +s+, using the equation in <<schnorr_signing_formula>>:
|
|
|
|
latexmath:[\(s⋅G = R + hash(R || A || m)⋅A\)]
|
|
|
|
Alice and only Alice can calculate +s+, because only Alice knows the secret values +a+ and +r+.
|
|
|
|
.Calculating +s+ for the Schnorr signature
|
|
****
|
|
The algebraic formula that Alice's software uses to calculate +s+ is based on her knowledge of the secret keys +r+ and +a+, works as follows:
|
|
|
|
++S = R + hash(R,A,m)⋅A++
|
|
|
|
++s⋅G = r⋅G + hash(R,A,m)⋅a⋅G++
|
|
|
|
++s⋅G = (r + hash(R,A,m)⋅a)⋅G++
|
|
|
|
++s = (r + hash(R,A,m)⋅a)++
|
|
|
|
Only Alice, since she knows +r+ and +a+, can find a value for +s+ that satisfies the signing formula:
|
|
|
|
++S = R + hash(R,A,m) ⋅ A++
|
|
|
|
****
|
|
|
|
===== Encoding the signature
|
|
|
|
The signature is encoded in the witness of the Bitcoin transaction as a serialized encoding of the pair of values (R, S), which allows anyone to verify the authenticity of the signature.
|
|
|
|
===== Verifying the signature
|
|
|
|
Given the signature +(R, S)+, the message (Bitcoin transaction) +m+, and the owner's public key +P+ a verifier can evaluate the same formula as in <<schnorr_signing_formula>> and see that the two parts are equal. Since the verifier does not have the private key +a+ or the ephemeral random key +r+, that were used to produce the points +A+ and +R+ respectively, they cannot themselves calculate a value +s+ that satisfies the formula. They can however, given the value +S+, verify that it works in the equation and thereby verify that the signature is authentic.
|