harding comments ch01-06

Author: jimmysong

ch01.asciidoc

@@ -64,15 +64,12 @@ That means 0 and 1 are in the set.
 
 (4) means that we have the additive inverse.
 That is, if *a* is in the set, *-a* is in the set.
-Using this, we can define subtraction.
-Subtraction is the inverse of addition.
-Once again, we have to make sure subtraction is defined in a way as to make sure that the result is still in the set, that is, not go under 0.
-In other words, we need to define subtraction to be _closed_.
+Using the additive inverse, we can define subtraction.
 
 (5) means that multiplication has the same property.
 If *a* is in the set, *a^-1^* is in the set.
 That is *a⋅a^-1^=1*.
-Using this, we can define division, the inverse of multiplication.
+Using the multiplicative inverse, we can define division.
 This will be the trickiest to define in a finite field.
 
 === Defining Finite Sets

ch03.asciidoc

@@ -517,7 +517,7 @@ The key operation that we need is `P=eG` which 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 Discrete Log is extremely difficult to create signing and verification.
+The difficulty of Discrete Log will be essential to understanding signing and verification algorithms.
 
 Generally, we call `e` the Private Key and P the Public Key.
 We'll note here that the private key is a single 256-bit number and the public key is a coordinate `(x,y)` where `x` and `y` are _each_ 256-bit numbers.
@@ -651,7 +651,7 @@ It's worth mentioning again, make sure you're using truly random numbers for `k`
 ==== Verification in-depth
 
 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`.
+The fact that 32 bytes is 256 bits is not a coincidence as the thing we're signing will be a scalar for `G`.
 
 In order to guarantee that the thing we're signing is 32 bytes, we hash the document first.
 In Bitcoin, the hashing function is hash256, or two rounds of sha256.
@@ -697,11 +697,11 @@ The calculation of `z` requires two rounds of sha256, or hash256.
 You may be wondering why there are two rounds when only 1 is necessary to get a 256-bit number.
 The reason is for security.
 
-There is a well-known hash collision attack on sha1 called a _birthday attack_ which basically makes finding collisions much easier.
-This is how Google found a sha1 collision in 2017 (https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html).
-Using sha1 twice, or double-sha1 is the way to defeat this attack.
+There is a well-known hash collision attack on sha1 called a _birthday attack_ which makes finding collisions much easier.
+Google found a sha1 collision using some modifications of a birthday attack and a lot of other things in 2017 (https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html).
+Using sha1 twice, or double-sha1 is the way to defeat slow down some forms of this attack.
 
-There is no known sha256 weakness like a birthday attack, but doing two rounds is a defense against similar potential weaknesses.
+Two rounds of sha256 don't necessarily prevent all possible attacks, but doing two rounds is a defense against some potential weaknesses.
 ====
 
 ==== Verifying a Signature
@@ -875,7 +875,7 @@ This makes transactions less malleable (more on that in <<chapter_segwit>>)
 ### Conclusion
 
 We've covered Elliptic Curve Cryptography and we can now prove that we know a secret by signing something and we can also verify that the person with the secret actually signed a message.
-Even if you don't read another page in this book, you've learned to implement what was once considered "weapons grade cryptography".
+Even if you don't read another page in this book, you've learned to implement what was once considered "weapons grade munitions" (see https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States).
 This is a major step in your journey and will be essential for the rest of the book!
 
 We now turn to serializing a lot of these structures so that we can store them on disk and send them over the network.

ch04.asciidoc

@@ -314,8 +314,8 @@ include::code-ch04/answers.py[tag=exercise4]
 
 === Address Format
 
-The 260 bits from a compressed SEC format is still a bit too long, not to mention a bit less secure (see <<chapter_script>>).
-To both shorten and increase security, we can use the ripemd160 hash to compress the public key to a 20-byte hash.
+The 264 bits from a compressed SEC format is still a bit too long, not to mention a bit less secure (see <<chapter_script>>).
+To both shorten and increase security, we can use the ripemd160 hash to reduce the size to a 20-byte hash.
 
 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:
@@ -349,8 +349,6 @@ We can implement this in `helper.py`.
 [source,python]
 ----
 include::code-ch04/helper.py[tag=source4]
-def hash160(s):
-    return hashlib.new('ripemd160', hashlib.sha256(s).digest()).digest()  # <1>
 ----
 <1> Note that `hashlib.sha256(s).digest()` does the sha256 and the wrapper around it does the ripemd160.
 
@@ -398,7 +396,7 @@ include::code-ch04/answers.py[tag=exercise6]
 === Big and Little Endian Redux
 
 It will be very useful to know how Big and Little Endian are done in Python as the next few chapters will be parsing and serializing numbers to and from Big/Little Endian quite a bit.
-In particular, Satoshi used a lot of Little-Endian for Bitcoin and unfortunately, there's no easy rule for determining where Little-Endian was used and where Big-Endian was used.
+In particular, Satoshi used a lot of Little-Endian for Bitcoin and unfortunately, there's no easy-to-learn rule for where Little-Endian is used and where Big-Endian is used.
 Recall that SEC format uses Big-Endian encoding as do addresses and WIF.
 From <<chapter_tx_parsing>> onward, we will use Little-Endian encoding a lot more.
 For this reason, we turn to the next two exercises.
@@ -410,7 +408,7 @@ include::code-ch04/answers.py[tag=exercise8]
 
 include::code-ch04/answers.py[tag=exercise9]
 
-Go to a testnet faucet (https://faucet.programmingbitcoin.com) and send some testnet coins to that address (it should start with `m` or `n`).
+Go to a testnet faucet (https://faucet.programmingbitcoin.com) and send some testnet coins to that address (it should start with `m` or `n` or else something is wrong).
 If you succeeded, congrats!
 You're now the proud owner of some testnet coins!
 

ch05.asciidoc

@@ -91,7 +91,7 @@ If, for example, you are running Windows 3.1, that's a version number that's ver
 You could specify just "Windows", but specifying the version number after the operating system helps you know what features it has and what API's you can program against.
 
 Similarly, Bitcoin transactions have version numbers.
-In Bitcoin's case, the transaction version is generally 1, but there are cases where it can be 2 (transactions using an opcode called `OP_CHECKSEQUENCEVERIFY` as defined in BIP68/BIP112/BIP113 require use of version > 1).
+In Bitcoin's case, the transaction version is generally 1, but there are cases where it can be 2 (transactions using an opcode called `OP_CHECKSEQUENCEVERIFY` as defined in BIP112 require use of version > 1).
 
 You may notice here that the actual value in hexadecimal is `01000000`, which doesn't look like 1.
 Interpreted as a Little-Endian integer, however, this number is actually 1 (recall the discussion from <<chapter_serialization>>).
@@ -106,7 +106,7 @@ image::tx3.png[Inputs]
 Each input points to an output of a previous transaction.
 This fact requires more explanation as it's not intuitively obvious at first.
 
-Bitcoin's inputs are spending outputs of another transaction.
+Bitcoin's inputs are spending outputs of a previous transaction.
 That is, you need to have received Bitcoins first to spend something.
 This makes intuitive sense.
 You cannot spend money unless you received money first.
@@ -226,7 +226,7 @@ include::code-ch05/tx.py[tag=source2]
 
 A couple things to note here.
 The amount of each input is not specified.
-We have no idea how much is being spent unless we look up the transaction in the blockchain.
+We have no idea how much is being spent unless we look up in the blockchain for the transaction(s) that we're spending.
 Furthermore, we don't even know if the transaction is unlocking the right box, so to speak, without knowing about the previous transaction.
 Every node must verify that this transaction unlocks the right box and that it doesn't spend non-existent Bitcoins.
 How we do that is discussed more in <<chapter_tx>>.

ch06.asciidoc

@@ -415,7 +415,9 @@ This makes the compressed and uncompressed SEC formats 66 and 130 characters res
 To compound this, early Bitcoin transactions didn't use the compressed versions so the hexadecimal addresses were 130 characters each!
 This is not fun or easy for people to transcribe, much less communicate by voice.
 
-That said, the original use-case for p2pk was for IP-to-IP payments where IP addresses were queried for their public keys, so communicating the public keys were done machine-to-machine, which meant that this wasn't necessarily a problem.
+That said, the original use-cases for p2pk were for IP-to-IP payments and mining outputs.
+For IP-to-IP payments, IP addresses were queried for their public keys, so communicating the public keys were done machine-to-machine, which meant that human communication wasn't necessarily a problem.
+Use for mining outputs also don't require human communication.
 Incidentally, this IP-to-IP payment system was phased out as it's not secure and prone to man-in-the-middle attacks.
 
 .Why did Satoshi use the uncompressed SEC format?
@@ -459,7 +461,7 @@ These 20 bytes are the result of doing a hash160 operation on this (compressed)
 
 `0250863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b2352`
 
-Given p2pkh is shorter and more secure, p2pk is no longer used much on the network.
+Given p2pkh is shorter and more secure, p2pk use declined significantly after 2010, though it's still fully supported today.
 
 === p2pkh