Andreas M. Antonopoulos
2 years ago
commit
eeca5dee4a
@ -0,0 +1,5 @@
|
||||
|
||||
[[bech32m]]
|
||||
=== SegWit v1 Addresses (bech32m)
|
||||
|
||||
https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
|
||||
|
After Width: | Height: | Size: 123 KiB |
|
After Width: | Height: | Size: 251 KiB |
|
After Width: | Height: | Size: 136 KiB |
|
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 316 KiB |
@ -0,0 +1,6 @@
|
||||
|
||||
[[mast]]
|
||||
=== Merkleized Abstract Syntax Trees
|
||||
|
||||
[[merkle_branches]]
|
||||
==== Merkle branches in SegWit v1
|
||||
@ -0,0 +1,83 @@
|
||||
[[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.
|
||||
|
||||
Illustration 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)]
|
||||
|
||||
[[schnorr_sigs_illustrated]]
|
||||
.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⋅G = R + hash(R || P || m)⋅P\)]
|
||||
|
||||
Let's work through this formula step-by-step, explaining the various components as they are build from the perspective of the software that is signing a specific Bitcoin transaction.
|
||||
|
||||
===== The wallet owner's private key (pk)
|
||||
First of all, the purpose of Bitcoin digital signatures is to prove ownership and allow spending of bitcoin in a transaction. The owner of the bitcoin is identified by a private key +pk+, which they have kept secret. The owner has derived a corresponding public key +P+, such that latexmath:[\(P = pk⋅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_ or _nonce_ value) +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.
|
||||
|
||||
===== 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 formula the Bitcoin transaction is denoted by the letter +m+, for "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 +P+, as follows:
|
||||
|
||||
latexmath:[\(hash( R || P || m )\)]
|
||||
|
||||
In Bitcoin's implementation of Schnorr signatures, the message is prefixed by +R+ and +P+ in the hash formula so as to _bind_ the signed message to those public keys, preventing a class of attacks called "related key attacks".
|
||||
|
||||
===== Calculating the signature value +s+
|
||||
|
||||
Finally, the signing software calculates a value +s+, using the equation in <<schnorr_signing_formula>>:
|
||||
|
||||
latexmath:[\(s⋅G = R + hash(R || P || m)⋅P\)]
|
||||
|
||||
===== 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 +pk+ or the nonce value +r+, that were used to produce the points +P+ 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.
|
||||
@ -0,0 +1,5 @@
|
||||
[[segwitv1]]
|
||||
[[taproot]]
|
||||
=== SegWit v1
|
||||
|
||||
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
|
||||
@ -0,0 +1,6 @@
|
||||
|
||||
[[taproot_scripts]]
|
||||
[[tapscript]]
|
||||
=== Taproot Scripts (Tapscript)
|
||||
|
||||
https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
|
||||
@ -1,6 +1,6 @@
|
||||
<section data-type="titlepage">
|
||||
<h1>Mastering Bitcoin</h1>
|
||||
<p class="edition">Second Edition</p>
|
||||
<p class="edition">Third Edition</p>
|
||||
<p class="subtitle">Programming the Open Blockchain</p>
|
||||
<p class="author">Andreas M. Antonopoulos</p>
|
||||
</section>
|
||||
|
||||
Loading…
Reference in new issue