more technical review items

Author: jimmysong

all.asciidoc

@@ -1,7 +1,7 @@
 = Programming Bitcoin
 Jimmy Song
 v2.0, 2018-12-03
-:imagesdir: images
+:imagesdir: .
 :doctype: book
 
 include::preface.asciidoc[]

ch01.asciidoc

@@ -43,7 +43,7 @@ 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, which 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.
+Let's unpack each of the above.
 
 We have a set of numbers that's finite.
 Because the set is finite, we can designate a number _p_, which is how big the set is.
@@ -108,11 +108,11 @@ A Finite Field of order 17 looks like this:
 </ul>
 ++++
 
-A Finite Field of order 981 looks like this:
+A Finite Field of order 983 looks like this:
 
 ++++
 <ul class="simplelist">
-<li>F<sub>981</sub>= {0, 1, 2, ... 980}</li>
+<li>F<sub>983</sub>= {0, 1, 2, ... 982}</li>
 </ul>
 ++++
 
@@ -134,7 +134,7 @@ The bare bones of the class look like this:
 include::code-ch01/ecc.py[tag=source1]
 ----
 <1> We first check that `num` is between `0` and `prime-1` inclusive.
-If not, we have an invalid Field Element and we raise a `ValueError`, which is what we should raise when we get an inappropriate value.
+If not, we get an invalid Field Element and we raise a `ValueError`, which is what we should raise when we get an inappropriate value.
 <2> The rest of the `__init__` method assigns the initialization values to the object.
 <3> The `__eq__` method checks if two objects of class `FieldElement` are equal.
 This is only true when the `num` and `prime` properties are equal.
@@ -506,7 +506,7 @@ include::code-ch01/answers.py[tag=exercise6,indent=0]
 ==== Coding Exponentiation in Python
 
 We need to define the exponentiation for `FieldElement`, which in Python can be defined with the `__pow__` method, overriding the `**` operator.
-The difference here is that the exponent is _not_ a `FieldElement`, so has to be treated a bit differently.
+The difference here is that the exponent is _not_ a `FieldElement`, so it has to be treated a bit differently.
 We want something like this to work:
 
 [source,python]
@@ -747,7 +747,7 @@ class FieldElement:
 ...
 include::code-ch01/ecc.py[tag=source3]
 ----
-<1> Make the exponent into something within the 0 to p–1 range.
+<1> Make the exponent into something within the 0 to p-2 range, inclusive.
 
 === Conclusion
 

ch02.asciidoc

@@ -290,7 +290,7 @@ 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.
+<4> `other.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,indent=0]
@@ -338,7 +338,7 @@ Using this formula and plugging it into the Elliptic Curve equation, we get:
 
 Gathering all the terms, we have this polynomial equation:
 
-* __x__^3^ – __s__^2^x^2^ + (__a__ + 2__s__^2^__x__~1~ – 2__sy__~1~)__x__ + __b__ – __x__~1~^2^ + 2__sx__~1~__y__~1~ – __y__~1~^2^ = 0
+* __x__^3^ – __s__^2^x^2^ + (__a__ + 2__s__^2^__x__~1~ – 2__sy__~1~)__x__ + __b__ – __s__^2^__x__~1~^2^ + 2__sx__~1~__y__~1~ – __y__~1~^2^ = 0
 
 We also know that __x__~1~, __x__~2~, and __x__~3~ are solutions to this equation, thus:
 
@@ -347,7 +347,7 @@ We also know that __x__~1~, __x__~2~, and __x__~3~ are solutions to this equatio
 
 From earlier, we know that:
 
-* __x__^3^ – __s__^2^x^2^ + (__a__ + 2__s__^2^__x__~1~ – 2__sy__~1~)__x__ + __b__ – __x__~1~^2^ + 2__sx__~1~__y__~1~ – __y__~1~^2^ = 0
+* __x__^3^ – __s__^2^x^2^ + (__a__ + 2__s__^2^__x__~1~ – 2__sy__~1~)__x__ + __b__ – __s__^2^__x__~1~^2^ + 2__sx__~1~__y__~1~ – __y__~1~^2^ = 0
 
 There's a result from what's called the https://en.wikipedia.org/wiki/Vieta%27s_formulas[Vieta's Formula], which states that the coefficients have to equal each other if the roots are the same.
 The first coefficient that's interesting is the coefficient in front of __x__^2^:

ch04.asciidoc

@@ -370,7 +370,6 @@ We can do steps 4 and 5 in one go this way:
 ----
 include::code-ch04/helper.py[tag=source3]
 ----
-<1> Note that the `.decode('ascii')` part is necessary to convert from Python 3 bytes to a Python 3 string.
 
 [NOTE]
 .What Is Testnet?

ch05.asciidoc

@@ -305,13 +305,19 @@ include::code-ch05/answers.py[tag=exercise3,indent=0]
 === Locktime
 
 Locktime is a way to time-delay a transaction.
-A transaction with a Locktime of 600,000 cannot go into the blockchain until block 600,000.
+A transaction with a Locktime of 600,000 cannot go into the blockchain until block 600,001.
 This was originally construed as a way to do "high-frequency trades" (see _Sequence and Locktime_), which turned out to be insecure.
 If the Locktime is greater than or equal to 500,000,000, Locktime is a UNIX timestamp.
 If Locktime is less than 500,000,000, it is a block number.
 This way, transactions can be signed, but unspendable until a certain point in UNIX time or block height.
 
-The serialization is in Little-Endian and is 4 bytes long (<<locktime>>).
+.When Locktime is Ignored
+[WARNING]
+====
+Note that Locktime is ignored if the sequence numbers for every input is `ffffffff`.
+====
+
+The serialization is in Little-Endian and 4-bytes (<<locktime>>).
 
 [[locktime]]
 .Locktime

ch06.asciidoc

@@ -150,7 +150,7 @@ Here are some operations and their byte codes:
 * `0x00` - `OP_0`
 * `0x51` - `OP_1`
 * `0x60` - `OP_16`
-* `0x75` - `OP_DUP`
+* `0x76` - `OP_DUP`
 * `0x93` - `OP_ADD`
 * `0xa9` - `OP_HASH160`
 * `0xac` - `OP_CHECKSIG`
@@ -284,7 +284,7 @@ Note the `OP_CHECKSIG`, as that will be very important.
 The ScriptSig is the part that unlocks the received bitcoins.
 The pubkey can be compressed or uncompressed, though early on in Bitcoin's history when p2pk was more prominent, uncompressed was the only one being used (see <<chapter_serialization>>).
 
-For p2pk, the ScriptSig required to unlock the corresponding ScriptPubKey is just the signature as shown in <<pay_to_pubkey_p2pk_scriptsig>>.
+For p2pk, the ScriptSig required to unlock the corresponding ScriptPubKey is the signature followed by a single sighash byte as shown in <<pay_to_pubkey_p2pk_scriptsig>>:
 
 [[pay_to_pubkey_p2pk_scriptsig]]
 .Pay-to-pubkey (p2pk) ScriptSig

ch09.asciidoc

@@ -247,7 +247,7 @@ To find a proof-of-work, the miners on the Bitcoin network have to churn through
 Like gold, verifying proof-of-work is much cheaper than actually finding it.
 
 So what is proof-of-work?
-Let's look at the hash256 of the block we saw before to find out:
+Let's look at the hash256 of the block header we saw before to find out:
 
 ```
 020000208ec39428b17323fa0ddec8e887b4a7c53b8c0a0a220cfd000000000000000000
@@ -290,7 +290,7 @@ The mechanics of how the Merkle Root changes whenever any transaction in the blo
 
 ==== Target
 
-Proof-of-work is the requirement that every block in Bitcoin must be below a certain target.
+Proof-of-work is the requirement that the hash of every block header in Bitcoin must be below a certain target.
 _Target_ is a 256-bit number that is computed directly from the bits field.
 The target is very small compared to an average 256-bit number.
 
@@ -320,12 +320,12 @@ include::code-ch09/examples.py[tag=example6]
 ----
 <1> We are purposefully printing this number as 64 hexadecimal digits to show how small the number is in 256-bit terms.
 
-A valid proof-of-work is a hash of the block that, when interpreted as a Little-Endian integer, is below the target number.
+A valid proof-of-work is a hash of the block header that, when interpreted as a Little-Endian integer, is below the target number.
 Proof-of-work hashes are exceedingly rare and the process of mining is the process of finding one of these hashes.
 To find a single proof-of-work with the above target, the network as a whole must calculate 3.8 &#215; 10^21^ hashes, which, when this block was found, was roughly every 10 minutes.
 To give this number some context, the best GPU miner in the world would need to run for 50,000 years on average to find a single proof-of-work below this target.
 
-We can check that this block's hash satisfies the proof-of-work:
+We can check that this block header's hash satisfies the proof-of-work:
 
 [source,python]
 ----

ch10.asciidoc

@@ -73,7 +73,7 @@ The timestamp field is 8 bytes (as opposed to 4 bytes in the block header) and i
 
 IP addresses can be IPv6, IPv4, or OnionCat (a mapping of TOR's `.onion` addresses to IPv6).
 If IPv4, the first 12 bytes are `00000000000000000000ffff` and the last 4 bytes are the IP.
-The port is 2 bytes Little-Endian. The default on mainnet is 8333, which maps to `208d` in Little-Endian hex.
+The port is 2 bytes Little-Endian. The default on mainnet is 8333, which maps to `8d20` in Little-Endian hex.
 
 A nonce is a number used by a node to detect a connection to itself.
 User Agent identifies the software being run.

ch12.asciidoc

@@ -157,7 +157,7 @@ include::code-ch12/answers.py[tag=exercise3,indent=0]
 === Loading a Bloom Filter
 
 Once a light client has created a Bloom Filter, it needs to let the full node know the details of the filter so the full node can send Proofs of Inclusion.
-The first thing a light client must do is set the optional relay flag in the version message (see <<chapter_networking>>) to 1.
+The first thing a light client must do is set the optional relay flag in the version message (see <<chapter_networking>>) to 0.
 This tells the full node not to send transaction messages unless they match a Bloom Filter or they have been specifically requested.
 After the relay flag, a light client then communicates to the full node the Bloom Filter itself.
 The command to set the Bloom Filter is called `filterload`.

ch13.asciidoc

@@ -143,7 +143,7 @@ Software that understands how to validate Segwit Version X will validate such tr
 === p2sh-p2wpkh
 
 p2wpkh is great, but unfortunately, this is a new type of Script and older wallets cannot send Bitcoins to p2wpkh ScriptPubKeys.
-p2wpkh uses a new address format called bech32, whose ScriptPubKeys older wallets don't know how to create.
+p2wpkh uses a new address format called bech32, defined in BIP173, whose ScriptPubKeys older wallets don't know how to create.
 
 The Segwit authors found an ingenious way to make Segwit backward compatible by using p2sh.
 We can "wrap" p2wpkh inside a p2sh.