made each sentence its own line

Author: jimmysong

ch01.asciidoc

@@ -34,13 +34,23 @@ Mathematically, a Finite Field is defined as follows:
 
 A finite set of numbers and two operations *+* (addition) and *⋅* (multiplication) that satisfy the following:
 
-1. If *a* and *b* are in the set, *a+b* and *a⋅b* are in the set.
+1.
+If *a* and *b* are in the set, *a+b* and *a⋅b* are in the set.
 We call this property _closed_
-2. The additive identity, *0* exists.
+2.
+The additive identity, *0* exists.
 This means *a + 0 = a*
-3. The multiplicative identity, *1* exists. This means *a ⋅ 1 = a*
-4. 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_.
-5. If *a* is in the set and is not 0, *a^-1^* is in the set. *a^-1^* is defined as the value that makes *a ⋅ a^-1^ = 1*. This is what we call the _multiplicative inverse_.
+3.
+The multiplicative identity, *1* exists.
+This means *a ⋅ 1 = a*
+4.
+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_.
+5.
+If *a* is in the set and is not 0, *a^-1^* is in the set.
+*a^-1^* is defined as the value that makes *a ⋅ a^-1^ = 1*.
+This is what we call the _multiplicative inverse_.
 
 Let's unpack each of the following.
 

ch02.asciidoc

@@ -200,9 +200,12 @@ While this doesn't prove the associativity of point addition, the visual should
 
 To code point addition, we're going to split it up into 3 steps:
 
-1. Where the points are in a vertical line or using the Identity.
-2. Where the points are not in a vertical line, but are different.
-3. Where the two points are the same.
+1.
+Where the points are in a vertical line or using the Identity.
+2.
+Where the points are not in a vertical line, but are different.
+3.
+Where the two points are the same.
 
 === Coding Point Addition
 
@@ -235,10 +238,13 @@ include::code-ch02/ecc.py[tag=source2]
 
 include::code-ch02/ecc.py[tag=source3]
 ----
-<1> x-coordinate and y-coordinate being `None` is how we signify the point at infinity. Note that the next if statement will fail if we don't return here.
+<1> x-coordinate and y-coordinate being `None` is how we signify the point at infinity.
+Note that the next if statement will fail if we don't return here.
 <2> We overload the `+` operator here
-<3> `self.x` being `None` means that `self` is the point at infinity, or the additive identity. Thus, we return `other`
-<4> `self.x` being `None` means that `other` is the point at infinity, or the additive identity. Thus, we return `self`
+<3> `self.x` being `None` means that `self` is the point at infinity, or the additive identity.
+Thus, we return `other`
+<4> `self.x` being `None` means that `other` is the point at infinity, or the additive identity.
+Thus, we return `self`
 
 include::code-ch02/answers.py[tag=exercise3]
 

ch03.asciidoc

@@ -16,11 +16,23 @@ Pi, sqrt(2), e+7th root of 19, etc are all part of real numbers.
 This worked because _real_ numbers are also a field.
 Note unlike a _finite_ field, there are an _infinite_ number of real numbers, but otherwise the same properties hold:
 
-1. if *a* and *b* are in the set, *a+b* and *a⋅b* is in the set. We call this property _closed_
-2. The additive identity, *0* exists. This means *a + 0 = a*
-3. The multiplicative identity, *1* exists. This means *a ⋅ 1 = a*
-4. 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_.
-5. If *a* is in the set and is not 0, *a^-1^* is in the set. *a^-1^* is defined as the value that makes *a ⋅ a^-1^ = 1*. This is what we call the _multiplicative inverse_.
+1.
+if *a* and *b* are in the set, *a+b* and *a⋅b* is in the set.
+We call this property _closed_
+2.
+The additive identity, *0* exists.
+This means *a + 0 = a*
+3.
+The multiplicative identity, *1* exists.
+This means *a ⋅ 1 = a*
+4.
+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_.
+5.
+If *a* is in the set and is not 0, *a^-1^* is in the set.
+*a^-1^* is defined as the value that makes *a ⋅ a^-1^ = 1*.
+This is what we call the _multiplicative inverse_.
 
 Clearly, all of these are true as normal addition and multiplication apply for the first part, additive and multiplicative identities 0 and 1 exist, -x is the additive inverse and 1/x is the multiplicative inverse.
 
@@ -86,7 +98,8 @@ We will do this using the results of Exercise 2.
 ----
 include::code-ch03/ecc.py[tag=source2]
 ----
-<1> We pass in `FieldElement` objects into the `Point` class for initialization. This will, in turn, use all the overloaded math operations in `FieldElement`
+<1> We pass in `FieldElement` objects into the `Point` class for initialization.
+This will, in turn, use all the overloaded math operations in `FieldElement`
 
 We can now run this test like so:
 
@@ -362,9 +375,13 @@ class Point:
     ...
 include::code-ch03/ecc.py[tag=source3]
 ----
-<1> `current` represents the point that's at the current bit. First time through the loop it represents 1*self, the second time, it will be 2*self, third time, 4*self, then 8*self and so on. We double the point each time. In binary the coefficients are 1, 10, 100, 1000, 10000, etc.
+<1> `current` represents the point that's at the current bit.
+First time through the loop it represents 1*self, the second time, it will be 2*self, third time, 4*self, then 8*self and so on.
+We double the point each time.
+In binary the coefficients are 1, 10, 100, 1000, 10000, etc.
 <2> We start the result at 0, or the point at infinity.
-<3> We are looking at whether the right-most bit is a 1. If it is, then we add the value of the current bit.
+<3> We are looking at whether the right-most bit is a 1.
+If it is, then we add the value of the current bit.
 <4> We need to double the point until we're past how big the coefficient can be.
 <5> We bit shift the coefficient to the right.
 
@@ -477,7 +494,8 @@ include::code-ch03/ecc.py[tag=source7]
 
 We now have an easier way to initialize a point on the secp256k1 curve, without having to define the a and b every time like we have to with the `Point` class.
 
-We can also define `__rmul__` a bit more efficiently since we know the order of the group, `n`. Since we're coding Python, we'll name this with a capital `N` to make it clear that `N` is a constant.
+We can also define `__rmul__` a bit more efficiently since we know the order of the group, `n`.
+Since we're coding Python, we'll name this with a capital `N` to make it clear that `N` is a constant.
 
 [source,python]
 ----
@@ -487,7 +505,8 @@ class S256Point(Point):
     ...
 include::code-ch03/ecc.py[tag=source8]
 ----
-<1> We can mod by `n` because nG=0. That is, every `n` times we cycle back to zero or the point at infinity.
+<1> We can mod by `n` because nG=0.
+That is, every `n` times we cycle back to zero or the point at infinity.
 
 We can now define G directly and keep it around since we'll be using it a lot going forward.
 
@@ -678,10 +697,14 @@ The only way we could know the details of R beforehand is if we know `e`.
 
 To whit, here are the steps:
 
-1. We are given (r, s) as the signature, `z` as the hash of the thing being signed and P, the public key (or public point) of the signer.
-2. We calculate u = z/s, v = r/s
-3. We calculate uG + vP = R
-4. If R's `x` coordinate equals `r`, the signature is valid.
+1.
+We are given (r, s) as the signature, `z` as the hash of the thing being signed and P, the public key (or public point) of the signer.
+2.
+We calculate u = z/s, v = r/s
+3.
+We calculate uG + vP = R
+4.
+If R's `x` coordinate equals `r`, the signature is valid.
 
 [NOTE]
 .Why two rounds of sha256?
@@ -708,7 +731,8 @@ include::code-ch03/examples.py[tag=example9]
 <1> Note that we use Fermat's Little Theorem for 1/s, since `n` is prime.
 <2> u = z/s
 <3> v = r/s
-<4> uG+vP = (r,y). We need to check that the x-coordinate is r
+<4> uG+vP = (r,y).
+We need to check that the x-coordinate is r
 
 include::code-ch03/answers.py[tag=exercise6]
 
@@ -733,8 +757,10 @@ class S256Point(Point):
 include::code-ch03/ecc.py[tag=source12]
 ----
 <1> `s_inv` (1/s) is calculated using Fermat's Little Theorem on the order of the group `n` which is prime.
-<2> u = z/s. Note that we can mod by `n` as that's the order of the group.
-<3> v = r/s. Note that we can mod by `n` as that's the order of the group.
+<2> u = z/s.
+Note that we can mod by `n` as that's the order of the group.
+<3> v = r/s.
+Note that we can mod by `n` as that's the order of the group.
 <4> uG+vP should be R
 <5> We check that the x-coordinate is `r`
 
@@ -748,11 +774,17 @@ We do this by choosing a random `k`.
 
 Signing Procedure:
 
-1. We are given `z`. We know `e` and eG=P.
-2. Choose a random `k`
-3. Calculate R=kG and r=x-coordinate of R
-4. Calculate s = (z+re)/k
-5. Signature is (r,s)
+1.
+We are given `z`.
+We know `e` and eG=P.
+2.
+Choose a random `k`
+3.
+Calculate R=kG and r=x-coordinate of R
+4.
+Calculate s = (z+re)/k
+5.
+Signature is (r,s)
 
 Note that the pubkey `P` has to be transmitted to whoever wants to verify and `z` must be known by the verifier.
 We'll see later that `z` is computed and P is sent along with the signature.
@@ -771,11 +803,13 @@ This library is for teaching purposes only, so please don't use any of the code
 ----
 include::code-ch03/examples.py[tag=example10]
 ----
-<1> This is an example of a "brain wallet" which is a way to keep the private key in your head without having to memorize something too difficult. Please don't use this for a real secret.
+<1> This is an example of a "brain wallet" which is a way to keep the private key in your head without having to memorize something too difficult.
+Please don't use this for a real secret.
 <2> This is the signature hash, or hash of the message that we're signing.
 <3> We're going to use a fixed `k` here for demonstration purposes.
 <4> kG = (r,y) so we take the `x` coordinate only
-<5> s = (z+re)/k. We can mod by `n` because we know this is a cyclical group of order `n`.
+<5> s = (z+re)/k.
+We can mod by `n` because we know this is a cyclical group of order `n`.
 <6> The public point needs to be known by the verifier
 
 include::code-ch03/answers.py[tag=exercise7]
@@ -807,11 +841,13 @@ class PrivateKey:
             s = N - s
         return Signature(r, s) # <6>
 ----
-<1> `randint` chooses a random integer from `[0,n)`. Please don't use this function in production as the random number from this library is not nearly random enough.
+<1> `randint` chooses a random integer from `[0,n)`.
+Please don't use this function in production as the random number from this library is not nearly random enough.
 <2> `r` is the x-coordinate of kG
 <3> We use Fermat's Little Theorem again and `n`, which is prime
 <4> s = (z+re)/k
-<5> It turns out that using the low-s value will get nodes to relay our transactions easier. This is for malleability reasons
+<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 a unique `k`
@@ -844,7 +880,8 @@ class PrivateKey:
 ...
 include::code-ch03/ecc.py[tag=source14]
 ----
-<1> We are using the deterministic `k` instead of a random one. Everything else about `sign` remains the same.
+<1> We are using the deterministic `k` instead of a random one.
+Everything else about `sign` remains the same.
 <2> This algorithm returns a candidate that's suitable.
 
 Deterministic `k` will be unique with very high probability.

ch04.asciidoc

@@ -21,9 +21,12 @@ There are two forms of SEC format that we need to be concerned with and the firs
 
 Here is how the uncompressed SEC format for a given point P=(x,y) is generated:
 
-1. Start with the prefix byte which is `0x04`.
-2. Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
-3. Next, append the y-coordinate in 32 bytes as a Big-Endian integer.
+1.
+Start with the prefix byte which is `0x04`.
+2.
+Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
+3.
+Next, append the y-coordinate in 32 bytes as a Big-Endian integer.
 
 Here is what the uncompressed SEC format looks like:
 
@@ -67,7 +70,8 @@ class S256Point(Point):
 	return b'\x04' + self.x.num.to_bytes(32, 'big') \
             + self.y.num.to_bytes(32, 'big')  # <1>
 ----
-<1> In Python 3, you can convert a number to `bytes` using the `to_bytes` method. The first argument is how many bytes it should take up and the second argument is the endianness (see _Big and Little Endian_).
+<1> In Python 3, you can convert a number to `bytes` using the `to_bytes` method.
+The first argument is how many bytes it should take up and the second argument is the endianness (see _Big and Little Endian_).
 
 include::code-ch04/answers.py[tag=exercise1]
 
@@ -95,8 +99,11 @@ We call this the *Compressed SEC format* because of how the y-coordinate is comp
 
 Here is the serialization of the Compressed SEC format for a given point P=(x,y):
 
-1. Start with the prefix byte. If `y` is even, it's `0x02`, otherwise it's `0x03`.
-2. Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
+1.
+Start with the prefix byte.
+If `y` is even, it's `0x02`, otherwise it's `0x03`.
+2.
+Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
 
 The Compressed SEC format looks like this:
 
@@ -205,12 +212,22 @@ This was most likely because the standard was already defined in 2008, supported
 
 DER Signature format is defined like this:
 
-1. Start with the `0x30` byte
-2. Encode the length of the rest of the signature (usually `0x44` or `0x45`) and append
-3. Append the marker byte `0x02`
-4. Encode `r` as a Big-Endian integer, but prepend with `0x00` byte if `r`'s first byte >= `0x80`. Prepend the resulting length to `r`. Add this to the result.
-5. Append the marker byte `0x02`
-6. Encode `s` as a Big-Endian integer, but prepend with `0x00` byte if `s`'s first byte >= `0x80`. Prepend the resulting length to `s`. Add this to the result.
+1.
+Start with the `0x30` byte
+2.
+Encode the length of the rest of the signature (usually `0x44` or `0x45`) and append
+3.
+Append the marker byte `0x02`
+4.
+Encode `r` as a Big-Endian integer, but prepend with `0x00` byte if `r`'s first byte >= `0x80`.
+Prepend the resulting length to `r`.
+Add this to the result.
+5.
+Append the marker byte `0x02`
+6.
+Encode `s` as a Big-Endian integer, but prepend with `0x00` byte if `s`'s first byte >= `0x80`.
+Prepend the resulting length to `s`.
+Add this to the result.
 
 The rules for #4 and #6 with the first byte starting with something greater than or equal to `0x80` is because DER is a general encoding and allows for negative numbers to be encoded.
 The first bit being 1 means that the number is negative.
@@ -284,9 +301,12 @@ include::code-ch04/helper.py[tag=source1]
 ...
 include::code-ch04/helper.py[tag=source2]
 ----
-<1> The purpose of this loop is to determine how many of the bytes at the front are 0 bytes. We want to add them back at the end.
+<1> The purpose of this loop is to determine how many of the bytes at the front are 0 bytes.
+We want to add them back at the end.
 <2> This is the loop that figures out what Base58 digit to use.
-<3> Finally, we prepend all the zeros that we counted at the front because otherwise, they wouldn't show up as prefixed 1's. This annoyingly happens with pay-to-pubkey-hash (p2pkh). More on that in <<chapter_script>>.
+<3> Finally, we prepend all the zeros that we counted at the front because otherwise, they wouldn't show up as prefixed 1's.
+This annoyingly happens with pay-to-pubkey-hash (p2pkh).
+More on that in <<chapter_script>>.
 
 This function will take any bytes in Python 3 and convert it to Base58.
 
@@ -311,11 +331,16 @@ To both shorten and increase security, we can use the ripemd160 hash to compress
 By not using the SEC format directly, we can go from 33 bytes to 20 bytes, shortening the address significantly.
 Here is how a Bitcoin address is created:
 
-1. For mainnet addresses, start with the prefix `0x00`, for testnet `0x6f`.
-2. Take the SEC format (compressed or uncompressed) and do a sha256 operation followed by the ripemd160 hash operation, the combination which is called a hash160 operation.
-3. Combine the prefix from #1 and resulting hash from #2
-4. Do a hash256 of the result from #3 and get the first 4 bytes.
-5. Take the combination of #3 and #4 and encode in Base58.
+1.
+For mainnet addresses, start with the prefix `0x00`, for testnet `0x6f`.
+2.
+Take the SEC format (compressed or uncompressed) and do a sha256 operation followed by the ripemd160 hash operation, the combination which is called a hash160 operation.
+3.
+Combine the prefix from #1 and resulting hash from #2
+4.
+Do a hash256 of the result from #3 and get the first 4 bytes.
+5.
+Take the combination of #3 and #4 and encode in Base58.
 
 Step 4 of this process is called the checksum.
 We can do steps 4 and 5 in one go this way:
@@ -368,12 +393,18 @@ WIF uses the same Base58 encoding that addresses use.
 
 Here is how the WIF format is created:
 
-1. For mainnet private keys, start with the prefix `0x80`, for testnet `0xef`.
-2. Encode the secret in 32-byte Big-Endian.
-3. If the SEC format used for the public key address was compressed add a suffix of `0x01`.
-4. Combine the prefix from #1, serialized secret from #2 and suffix from #3
-5. Do a hash256 of the result from #4 and get the first 4 bytes.
-6. Take the combination of #4 and #5 and encode in Base58.
+1.
+For mainnet private keys, start with the prefix `0x80`, for testnet `0xef`.
+2.
+Encode the secret in 32-byte Big-Endian.
+3.
+If the SEC format used for the public key address was compressed add a suffix of `0x01`.
+4.
+Combine the prefix from #1, serialized secret from #2 and suffix from #3
+5.
+Do a hash256 of the result from #4 and get the first 4 bytes.
+6.
+Take the combination of #4 and #5 and encode in Base58.
 
 We can now create the `wif` method on the `PrivateKey` class.