caswell feedback

ch01.asciidoc

@@ -27,7 +27,7 @@ Mathematically, a Finite Field is defined as follows:
 
 A finite set of numbers and two operations *+* (addition) and *⋅* (multiplication) that satisfy the following:
 
-* If *a* and *b* are in the set, *a+b* and *a⋅b* is in the set. We call this property _closed_
+* If *a* and *b* are in the set, *a+b* and *a⋅b* are in the set. We call this property _closed_
 * The additive identity, *0* exists. This means *a + 0 = a*
 * The multiplicative identity, *1* exists. This means *a ⋅ 1 = a*
 * If *a* is in the set, *-a* is in the set. *-a* is defined as the value that makes *a + (-a) = 0*. This is what we call the _additive inverse_.
@@ -565,4 +565,4 @@ Thankfully, we can do even better. We already know how to force a number into th
 
 === Conclusion
 
-In thes chapter we learned about Finite Fields and how to implement it in Python. We'll be utilizing thes in Chapter 3 for Elliptic Curve Cryptography. We turn next to the other mathematical component that we need and that's Elliptic Curves.
+In this chapter we learned about Finite Fields and how to implement it in Python. We'll be utilizing thes in Chapter 3 for Elliptic Curve Cryptography. We turn next to the other mathematical component that we need and that's Elliptic Curves.

ch02.asciidoc

@@ -15,7 +15,7 @@ Elliptic Curves are really just like many equations you've been seeing since aro
 
 y^2^=x^3^+ax+b
 
-This is probably somewhat familiar as you've worked with other equations that look similar. For example, you are probably learned the linear equation back in middle school:
+This is probably somewhat familiar as you've worked with other equations that look similar. For example, you probably learned the linear equation back in pre-algebra:
 
 y = mx + b
 
@@ -142,7 +142,7 @@ Like Field Addition, we are defining Point Addition. In our case, Point Addition
 
 For any two points P~1~=(x~1~,y~1~) and P~2~=(x~2~,y~2~), we get P~1~+P~2~ by:
 
-* Find the point intersects the elliptic curve a third time by drawing a line through P~1~ and P~2~
+* Find the point intersecting the elliptic curve a third time by drawing a line through P~1~ and P~2~
 * Reflect the resulting point over the x-axis
 
 Visually, it looks something like this:

ch03.asciidoc

@@ -32,8 +32,8 @@ What's interesting is that we can use this equation over any field, including th
 
 For example, we can see what to do for the equation y^2^=x^3^+7 over F~103~. Let's see if the point (17,64) is on the curve:
 
-64^2^%103=79
-(17^3^+7)%103=79
+* 64^2^%103=79
+* (17^3^+7)%103=79
 
 Indeed, that point is on the curve using the Finite Field math.
 
@@ -386,9 +386,9 @@ You can swap P~1~ and P~2~ to get the exact same equation.
 
 This is the hardest to prove but can be seen visually from the last chapter:
 
-.(P+Q)+R
+.(A+B)+C
 image::associativity1.png[Case 1]
-.P+(Q+R)
+.A+(B+C)
 image::associativity2.png[Case 2]
 
 Mathematically, this is a bit more involved, but the math can be proven given the definition that we have. There are proofs of this, but the polynomials involved take several pages and are thus outside the scope of this book.
@@ -619,7 +619,7 @@ Point(infinity)
 
 We can now describe Public Key Cryptography and how we can use Elliptic Curves over finite fields to build this up. In general, we need a finite cyclical group, which we have with point addition in order to make everything work.
 
-The key here is that when we have `P=eG` that this is an *asymmetric* equation. We can easily compute P when we know e and G, but we cannot easily compute s when we know P and G. This is the Discrete Log Problem described earlier.
+The key here is that when we have `P=eG` that this is an *asymmetric* equation. We can easily compute P when we know e and G, but we cannot easily compute e when we know P and G. This is the Discrete Log Problem described earlier.
 
 We'll use the fact that it's extremely difficult to compute e to create signing and verification.
 
@@ -720,7 +720,7 @@ It's worth mentioning again, make sure you're using truly random numbers for `k`
 
 Generally, signatures sign some fixed-length value (our "contract"), in our case something that's 32 bytes. The fact that 32 bytes is 256 bits is not a coincidence as the thing we're signing needs to be a scalar for G.
 
-In order to guarantee that thing we're signing is 32 bytes, we hash the document first. In Bitcoin, the hashing function is double-sha256. This guarantees the thing that we're signing is exactly 32 bytes. We will call the result of the hash, z.
+In order to guarantee that the thing we're signing is 32 bytes, we hash the document first. In Bitcoin, the hashing function is double-sha256. This guarantees the thing that we're signing is exactly 32 bytes. We will call the result of the hash, z.
 
 The actual signature that we are verifying has two components, (r, s). The r is as above, it's the x-coordinate of some point R that we'll come back to. s is going to be defined as this:
 
@@ -947,20 +947,23 @@ class PrivateKey:
 <5> It turns out that using the low-s value will get nodes to relay our transactions easier. This is for malleability reasons
 <6> We return a Signature object from above.
 
-.Importance of k being random
+.Importance of a unique `k`
 ****
-There's an important rule in signatures that utilize a random component like we have here. The `k` needs to be really random. That is, it cannot get reused. In fact, a `k` that's reused will result in you losing your secret! This is because:
+There's an important rule in signatures that utilize a random component like we have here. The `k` needs to be unique per signature. That is, it cannot get reused. In fact, a `k` that's reused will result in you losing your secret! This is because:
 
-Our secret is e and our z is the same.
+Our secret is e, we are reusing k to sign z~1~ and z~2~.
 
-* k~1~G=(r~1~,y), k~2~G=(r~2~,y)
-* s~1~ = (z+r~1~e), s~2~ = (z+r~2~e)
-* s~1~-s~2~ = (r~1~-r~2~)e
-* e = (s~1~-s~2~) / (r~1~-r~2~)
+* kG=(r,y)
+* s~1~ = (z~1~+re) / k, s~2~ = (z~2~+re) / k
+* s~1~/s~2~ = (z~1~+re) / (z~2~+re)
+* s~1~(z~2~+re) = s~2~(z~1~+re)
+* s~1~z~2~ + s~1~re = s~2~z~1~ + s~2~re
+* s~1~re - s~2~re = s~2~z~1~ - s~1~z~2~
+* e = (s~2~z~1~ - s~1~z~2~) / (rs~1~ - rs~2~)
 
-If anyone sees both signatures, they can run this formula and find our secret!
+If anyone sees both signatures, they can use this formula and find our secret!
 
-To combat this, there is a deterministic k generation standard which uses our secret and z to create a unique k every time. The specification is laid out in RFC6979 and the code changes to look like this:
+To combat this, there is a deterministic k generation standard which uses our secret and z to create a unique, deterministic k every time. The specification is laid out in RFC6979 and the code changes to look like this:
 
 [source,python]
 ----

ch04.asciidoc

@@ -6,7 +6,7 @@
 == Serialization
 
 [.lead]
-We've created a lot of classes thus far, including `PrivateKey`, `S256Point` and `Signature`. We now need to start thinking about how to transmit thes objects to other computers on the network, or even to disk as we'll need to store objects of these classes. This is where serialization comes into play. We want to communicate or store a `S256Point` or a `Signature` or a `PrivateKey`. Ideally, we want to do this efficiently for reasons we'll see in Chapter 10 (Networking).
+We've created a lot of classes thus far, including `PrivateKey`, `S256Point` and `Signature`. We now need to start thinking about how to transmit these objects to other computers on the network, or even to disk as we'll need to store objects of these classes. This is where serialization comes into play. We want to communicate or store a `S256Point` or a `Signature` or a `PrivateKey`. Ideally, we want to do this efficiently for reasons we'll see in Chapter 10 (Networking).
 
 === Uncompressed SEC format
 
@@ -37,7 +37,7 @@ Since Computers work in bytes, which have 8 bits, we have to think in base-256.
 Unfortunately, some stuff in Bitcoin (like the SEC format x and y coordinates) are in Big-Endian. Other stuff in Bitcoin (like the transaction version number) are in Little-Endian. This book will let you know which ones are Big vs Little Endian.
 ====
 
-This procedure is pretty straightforward. The trickiest part being converting a 256-bit number into a 32 bytes. Here's how this is done in code:
+This procedure is pretty straightforward. The trickiest part being converting a 256-bit number into 32 bytes. Here's how this is done in code:
 
 [source,python]
 ----