CH08: edits for feedback from Murch

- Drop box with Wikipedia definition of digital signatures.  It didn't
  add anything and its accuracy was debatable.

- Use "commitment hash" earlier and more often.

- Fix some variable-name errors in the math

- Correct info about worst-case signature verification cost

chapters/authorization-authentication.adoc

@@ -1377,7 +1377,7 @@ would have to include a signature within the transaction input:
 ----
 [...]
 "vin" : [
-"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
+"txid": "abcdef12345...",
 "vout": 0,
      	 "scriptSig": “<Bob’s scriptSig>”,
 ]
@@ -1392,7 +1392,7 @@ input script and includes a witness structure:
 ----
 [...]
 "vin" : [
-"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
+"txid": "abcdef12345...",
 "vout": 0,
      	 "scriptSig": “”,
 ]

chapters/signatures.adoc

@@ -15,59 +15,42 @@ Any time one of those is executed, a signature must be
 provided.
 
 ((("digital signatures", "purposes of")))A digital signature serves
-three purposes in Bitcoin (see the following sidebar). First, the
+three purposes in Bitcoin. First, the
 signature proves that the controller of a private key, who is by
 implication the owner of the funds, has _authorized_ the spending of
 those funds. Secondly, the proof of authorization is _undeniable_
-(nonrepudiation). Thirdly, the signature proves that specific parts of
+(nonrepudiation). Thirdly, that the authorized transaction cannot be
-the transaction have not and _cannot be modified_ by
+changed by unauthenticated third parties--that its _integrity_ is
-anyone besides the signer.
+intact.
-
-Note that each transaction input is signed independently. This is
-critical, as neither the signatures nor the inputs have to belong to or
-be applied by the same "owners." In fact, a specific transaction scheme
-called "CoinJoin" uses this fact to create multi-party transactions for
-privacy.
 
 [NOTE]
 ====
 Each transaction input and any signatures it may contain is _completely_
 independent of any other input or signature. Multiple parties can
 collaborate to construct transactions and sign only one input each.
+Several protocols uses this fact to create multi-party transactions for
+privacy.
 ====
 
-[[digital_signature_definition]]
-.Wikipedia's Definition of a "Digital Signature"
-****
-((("digital signatures", "defined")))A digital signature is a
-mathematical scheme for demonstrating the authenticity of a digital
-message or documents. A valid digital signature gives a recipient reason
-to believe that the message was created by a known sender
-(authentication), that the sender cannot deny having sent the message
-(nonrepudiation), and that the message was not altered in transit
-(integrity).
-
-_Source: https://en.wikipedia.org/wiki/Digital_signature_
-****
-
 In this chapter we look at how digital signatures work and how they can
 present proof of control of a private key without revealing that private
 key.
 
 === How Digital Signatures Work
 
-((("digital signatures", "how they work")))A digital signature is a
+((("digital signatures", "how they work")))A digital signature
-_mathematical scheme_ that consists of two parts. The first part is an
+consists of two parts. The first part is an algorithm for creating a
-algorithm for creating a signature, using a private key (the signing
+signature for a message (the transaction) using a private key (the
-key), from a message (the transaction). The second part is an algorithm
+signing key). The second part is an algorithm
 that allows anyone to verify the signature, given also the message and a
 public key.
 
 ==== Creating a digital signature
 
-In Bitcoin's implementation of digital signature algorithms, the "message" being
+In Bitcoin's use of digital signature algorithms, the "message" being
 signed is the transaction, or more accurately a hash of a specific
-subset of the data in the transaction (see <<sighash_types>>). The
+subset of the data in the transaction, called the _commitment hash_ (see
+<<sighash_types>>). The
 signing key is the user's private key. The result is the signature:
 
 latexmath:[\(Sig = F_{sig}(F_{hash}(m), x)\)]
@@ -75,7 +58,7 @@ latexmath:[\(Sig = F_{sig}(F_{hash}(m), x)\)]
 where:
 
 * _x_ is the signing private key
-* _m_ is the message to sign (such as parts of a transaction)
+* _m_ is the message to sign, the commitment hash (such as parts of a transaction)
 * _F_~_hash_~ is the hashing function
 * _F_~_sig_~ is the signing algorithm
 * _Sig_ is the resulting signature
@@ -96,27 +79,27 @@ simpler serialization format is used.
 
 ==== Verifying the Signature
 
-((("digital signatures", "verifying")))To verify the signature, one must
+((("digital signatures", "verifying"))) The signature verification
-have the signature, the serialized transaction, some data about the
+algorithm takes the message (a hash of parts of the transaction and
-output being spent, and the public key that corresponds to the private key used to create the
+related data), the signer's public key and the signature, and returns
-signature. Essentially, verification of a signature means "Only the
+TRUE if the signature is valid for this message and public key.
-controller of the private key that generated this public key could have
-produced this signature on this transaction."
 
-The signature verification algorithm takes the message (a hash of
+To verify the signature, one must have the signature, the serialized
-parts of the transaction and related data), the signer's public key and the signature,
+transaction, some data about the output being spent, and the public key
-and returns TRUE if the signature is valid for
+that corresponds to the private key used to create the signature.
-this message and public key.
+Essentially, verification of a signature means "Only the controller of
+the private key that generated this public key could have produced this
+signature on this transaction."
 
 [[sighash_types]]
 ==== Signature Hash Types (SIGHASH)
 
 ((("digital signatures", "signature hash
-types")))((("commitment")))Digital signatures are applied to messages,
+types")))((("commitment")))Digital signatures apply to messages,
 which in the case of Bitcoin, are the transactions themselves. The
-signature implies a _commitment_ by the signer to specific transaction
+signature prove a _commitment_ by the signer to specific transaction
 data. In the simplest form, the signature applies to almost the entire
-transaction, thereby committing all the inputs, outputs, and other
+transaction, thereby committing to all the inputs, outputs, and other
 transaction fields. However, a signature can commit to only a subset of
 the data in a transaction, which is useful for a number of scenarios as
 we will see in this section.
@@ -133,7 +116,7 @@ transaction.
 
 Remember, each input may contain one or more signatures. As
 a result, an input may have signatures
-with different +SIGHASH+ flags that commit different parts of the
+with different +SIGHASH+ flags that commit to different parts of the
 transaction. Note also that Bitcoin transactions
 may contain inputs from different "owners," who may sign only one input
 in a partially constructed transaction, collaborating with
@@ -179,8 +162,8 @@ either omitted or truncated (set to zero length and emptied). The resulting tran
 serialized. The +SIGHASH+ flag is included in the serialized
 transaction data and the result is hashed. The hash digest itself is the "message"
 that is signed. Depending on which +SIGHASH+ flag is used, different
-parts of the transaction are included. The resulting hash depends on
+parts of the transaction are included.
-different subsets of the data in the transaction. By including the
+By including the
 +SIGHASH+ flag itself, the signature commits the
 +SIGHASH+ type as well, so it can't be changed (e.g., by a miner).
 
@@ -217,10 +200,10 @@ someone who lends them funds), allowing them to collect the donations
 even if they haven't reached the specified value.
 
 +NONE+ :: This construction can be used to create a "bearer check" or
-"blank check" of a specific amount. It commits to the input, but allows
+"blank check" of a specific amount. It commits to all inputs, but allows
-the output script to be changed. Anyone can write their own
+the outputs to be changed. Anyone can write their own
-Bitcoin address into the output script. However, the output value
+Bitcoin address into the output script.
-itself cannot be changed.  By itself, this allows any miner to change
+By itself, this allows any miner to change
 the output destination and claim the funds for themselves, but if other
 required signatures in the transaction use +SIGHASH_ALL+ or another type
 that commits to the output, it allows those spenders to change the
@@ -248,7 +231,7 @@ destination.
 
 A signature using +SIGHASH_ANYPREVOUTANYSCRIPT+ would not
 commit to the outpoint, the amount, the witness program, or the
-tapleaf_hash used, allowing it to spend any previous output
+specific leaf in the taproot merkle tree (script tree), allowing it to spend any previous output
 which the signature could satisfy.  For example, if Alice received two
 outputs for different amounts and different witness programs (e.g. one
 requiring a single signature and another requiring her signature plus some
@@ -394,7 +377,7 @@ Of course, this is an oversimplified example.  When working with simple
 integers, we can divide products by the generator +G+ to get the
 underlying scalar, which isn't secure.  This is why a critical property
 of the Elliptic Curve Cryptography (ECC) used in Bitcoin is that
-multiplication is easy but division is impractical.  Also, with numbers
+multiplication is easy but division by a point on the curve is impractical.  Also, with numbers
 this small, finding underlying values (or valid substitutes) through
 brute force is easy; the numbers used in Bitcoin are much larger.
 ****
@@ -405,9 +388,9 @@ identity protocol that make it secure:
 - The nonce (+k+).  In step 1, Alice chooses a number that Bob doesn't
   know and can't guess and gives him the scaled form of that number,
   +kG+.  At that point, Bob also already has her public key (+xG+),
-  which is the scaled form of +x+.  That means when Bob is working on
+  which is the scaled form of +x+, her private key.  That means when Bob is working on
   the final equation (+sG = kG + exG+), there are two independent
-  variables that Bob doesn't know (+xG+ and +kG+).  It's possible to use
+  variables that Bob doesn't know (+x+ and +k+).  It's possible to use
   simple algebra to solve an equation with one unknown variable but not
   two independent unknown variables, so the presence of Alice's nonce
   prevents Bob from being able to derive her private key.  It's critical
@@ -417,7 +400,7 @@ identity protocol that make it secure:
   <<nonce_warning>> for more details.
 
 - The challenge scalar (+e+).  Bob waits to receive Alice's public nonce
-  and then proceeds in step 2 to giver her a number (the challenge
+  and then proceeds in step 2 to give her a number (the challenge
   scalar) that Alice didn't previously know and couldn't have guessed.
   It's critical that Bob only give her the challenge scalar after she
   commits to her public nonce.  Consider what could happen if someone
@@ -478,11 +461,11 @@ explicitly, the verification equation becomes +sG == kG + hash(kG) * xG+.
 We need one other thing to finish converting the interactive schnorr
 identity protocol into a digital signature protocol useful for
 Bitcoin.  We don't just want Alice to prove that she knows her private
-key; we also want to give her the to ability to commit to a message.  Specifically,
+key; we also want to give her the ability to commit to a message.  Specifically,
 we want her to commit to the data related to the Bitcoin transaction she
 wants to send.  With the Fiat-Shamir transform in place, we already
 have a commitment, so we can simply have it additionally commit to the
-message.  Instead of +hash(kG)+, we now also commit to to the message
+message.  Instead of +hash(kG)+, we now also commit to the message
 +m+ using +hash(kG || m)+, where +||+ stands for concatenation.
 
 We've now defined a version of the schnorr signature protocol, but
@@ -522,7 +505,7 @@ she's ready to spend, she begins generating her signature:
    are her signature.  She gives this signature to everyone who wants to
    verify that signature; she also needs to ensure everyone receives her
    message +m+.  In Bitcoin, this is done by including her signature in
-   the witness of her spending transaction and then relaying that
+   the witness structure of her spending transaction and then relaying that
    transaction to full nodes.
 
 4. The verifiers (e.g. full nodes) use +s+ to derive +sG+ and then
@@ -620,7 +603,7 @@ the private key for +z+, i.e. Bob's private key.  Now Bob can create a
 valid signature without any assistance from Alice.  This is called a
 _key cancellation attack_.
 
-There are various ways to solve to the key cancellation attack.  The
+There are various ways to solve the key cancellation attack.  The
 simplest scheme would be to require each participant commit to their
 part of the public key before sharing anything about that key with all
 of the other participants.  For example, Alice and Bob each individually
@@ -716,7 +699,7 @@ number of shares.  For example, Alice can choose a threshold (_k_) of
 +2+ if she wants any two of Bob, Carol, and Dan to be able to
 reconstruct her secret.  The best known secure secret sharing algorithm
 is _Shamir's Secret Sharing Scheme_, commonly abbreviated SSSS and named
-after its discoverer, one of the same discovers of the Fiat-Shamir
+after its discoverer, one of the same discoverers of the Fiat-Shamir
 transform we saw in <<schnorr_signatures>>.
 
 In some cryptographic protocols, such as the scriptless threshold signature
@@ -764,7 +747,7 @@ multisignature produced by a process that involved Carol and one that
 didn't.  Even if Alice, Bob, or Carol claim that they didn't sign,
 there's no guaranteed way for them to prove that they didn't
 help produce the signature.  If it's important to know which members of
-the group signed, you will need to use scripted threshold signatures.
+the group signed, you will need to use a script.
 
 2. Manipulation attacks: imagine that Bob tells Alice that Carol is
 unavailable, so they work together to reconstruct Carol's partial
@@ -795,7 +778,7 @@ using the schnorr signature scheme developed an alternative construction
 called the _Digital Signature Algorithm_ (DSA), with a version adapted
 to Elliptic Curves called ECDSA.
 
-The ECDSA scheme and standardized parameters for curves it could be used
+The ECDSA scheme and standardized parameters for suggested curves it could be used
 with were widely implemented in cryptographic libraries by the time
 development on Bitcoin began in 2007.  This was almost certainly the
 reason why ECDSA was the only digital signature protocol that Bitcoin
@@ -837,15 +820,8 @@ values are _R_ and _S_.
 
 ((("public and private keys", "key pairs", "ephemeral")))The signature
 algorithm first generates a private nonce (_k_) and derives from it a public
-nonce (_K_). These are used in the calculation of the _R_ and
+nonce (_K_).  The _R_ value of the digital signature is then the x
-_S_ values, after a transformation involving the signing private key and
+coordinate of the ephemeral public key _K_.
-the transaction hash.
-
-From _k_, we generate the corresponding
-public nonce _K_ (calculated as _K = k*G_, in the same way
-bitcoin public keys are derived; see <<public_key_derivation>>). The _R_ value of the
-digital signature is then the x coordinate of the ephemeral public key
-_K_.
 
 From there, the algorithm calculates the _S_ value of the signature,
 such that:
@@ -861,11 +837,11 @@ where:
 * _p_ is the prime order of the elliptic curve
 
 Verification is the inverse of the signature generation function, using
-the _R_, _S_ values and the public key to calculate a value _P_, which
+the _R_, _S_ values and the public key to calculate a value _K_, which
 is a point on the elliptic curve (the public nonce used in
 signature creation):
 
-_P_ = __S__^-1^ * __Hash__(__m__) * _G_ + __S__^-1^ * _R_ * _X_
+_K_ = __S__^-1^ * __Hash__(__m__) * _G_ + __S__^-1^ * _R_ * _X_
 
 where:
 
@@ -874,7 +850,7 @@ where:
 - _m_ is the message (the transaction data that was signed)
 - _G_ is the elliptic curve generator point
 
-If the x coordinate of the calculated point _P_ is equal to _R_, then
+If the x coordinate of the calculated point _K_ is equal to _R_, then
 the verifier can conclude that the signature is valid.
 
 Note that in verifying the signature, the private key is neither known
@@ -884,8 +860,7 @@ nor revealed.
 ====
 ECDSA is necessarily a fairly complicated piece of math; a full
 explanation is beyond the scope of this book. A number of great guides
-online take you through it step by step: search for "ECDSA explained" or
+online take you through it step by step: search for "ECDSA explained".
-try this one: http://bit.ly/2r0HhGB[].
 ====
 
 [[serialization_of_signatures_der]]
@@ -921,10 +896,11 @@ is part of the DER encoding scheme.
 === The Importance of Randomness in Signatures
 
 ((("digital signatures", "randomness in")))As we saw in <<schnorr_signatures>> and <<ecdsa_signatures>>,
-the signature generation algorithm uses a random key _k_, as the basis
+the signature generation algorithm uses a random number _k_, as the basis
 for a private/public nonce pair. The value of _k_ is not
-important, _as long as it is random_. If the same value _k_ is used to
+important, _as long as it is random_. If signatures from the same
-produce two signatures on different messages (transactions), then the
+private key use the private nonce _k_ with different messages
+(transactions), then the
 signing _private key_ can be calculated by anyone. Reuse of the same
 value for _k_ in a signature algorithm leads to exposure of the private
 key!
@@ -981,11 +957,11 @@ the data indicating the signer's commitment to those values. For
 example, in a simple +SIGHASH_ALL+ type signature, the commitment hash
 includes all inputs and outputs.
 
-Unfortunately, the way the commitment hash was calculated introduced the
+Unfortunately, the way the legacy commitment hashes were calculated introduced the
-possibility that a node verifying the signature can be forced to perform
+possibility that a node verifying a signature can be forced to perform
 a significant number of hash computations. Specifically, the hash
-operations increase in O(n^2^) with respect to the number of signature
+operations increase roughly quadratically with respect to the number of
-operations in the transaction. An attacker could therefore create a
+inputs in the transaction. An attacker could therefore create a
 transaction with a very large number of signature operations, causing
 the entire Bitcoin network to have to perform hundreds or thousands of
 hash operations to verify the transaction.