test lists in asciidoc

Author: jimmysong

ch01.asciidoc

@@ -34,21 +34,16 @@ 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.
-We call this property _closed_
-2.
-The additive identity, *0* exists.
+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.
 This means *a + 0 = a*
-3.
-The multiplicative identity, *1* exists.
+3. The multiplicative identity, *1* exists.
 This means *a ⋅ 1 = a*
-4.
-If *a* is in the set, *-a* is in the set.
+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.
+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_.
 

ch07.asciidoc

@@ -3,23 +3,20 @@
 == Transaction Creation and Validation
 
 [.lead]
-One of the trickiest things to code in Bitcoin is the validating transactions.
-Another one is the act of creating the transaction itself.
-In this chapter, we'll cover the exact steps to validating transactions and creating transactions.
-In fact, we'll be creating a transaction for ourselves.
+One of the trickiest things to code in Bitcoin is validating transactions.
+Another one is creating transactions.
+In this chapter, we'll cover the exact steps to doing both.
+Towards the end of this chapter, we'll be creating a testnet transaction and broadcasting it.
 
 === Validating Transactions
 
 Every node, when receiving transactions makes sure that each transaction adheres to the network rules.
 This process is called _transaction validation_.
 Here are the main things that a node needs to check for:
 
-1.
-Inputs of the transaction are previously unspent
-2.
-Sum of the inputs are greater than or equal to the sum of the outputs
-3.
-ScriptSig actually unlocks the previous ScriptPubKey
+1. Inputs of the transaction are previously unspent
+2. Sum of the inputs are greater than or equal to the sum of the outputs
+3. ScriptSig actually unlocks the previous ScriptPubKey
 
 (1) prevents double-spending.
 Any input that's already been spent cannot be spent again.

ch11.asciidoc

@@ -268,7 +268,7 @@ We could also be clever and use `len(bin(total))-2`.
 <2> The merkle tree will hold the root level at index 0, the level below at index 1 and so on.
 In other words, the index is the "depth" from the top.
 <3> We have to go up to `max_depth + 1` as `range` goes to 1 less than the second argument in Python.
-<4> The number of items at any particular level is the number of total leaves divided halved at evry level above the leaf level, rounded up.
+<4> The number of items at any particular level is the number of total leaves halved at every level above the leaf level, rounded up.
 <5> We don't know yet what any of the hashes are, so we set them to `None`
 <6> Note again that `merkle_tree` is a list of lists of hashes, or a 2-dimensional array.