Flowers feedback

ch05.asciidoc

@@ -25,7 +25,7 @@ We'll go through each component in depth.
 
 Here is a hexadecimal dump of a typical transaction that shows which parts are which.
 
-.Transaction Components
+.Transaction Components, Version, Inputs, Output and Locktime
 image::tx1.png[Transaction Version, Inputs, Outputs and Locktime]
 
 The differently highlighted parts represent Version, Inputs, Outputs and Locktime respectively.
@@ -113,7 +113,7 @@ You cannot spend money unless you received money first.
 The inputs refer to Bitcoins that belong to you.
 There are two things that each input needs to have:
 
-* A reference to the previous Bitcoins you own
+* A reference to the previous Bitcoins you received
 * Proof that these are yours to spend
 
 The second part uses ECDSA (<<chapter_elliptic_curve_cryptography>>).
@@ -190,7 +190,7 @@ Sequence is also in Little-Endian and takes up 4 bytes.
 
 The fields of the input look like this:
 
-.The Fields of an Input
+.The Fields of an Input, Previous Tx, Previous Index, ScriptSig and Sequence
 image::tx5.png[Input Fields]
 
 .Sequence and Locktime
@@ -271,7 +271,7 @@ Like ScriptSig, ScriptPubKey is a variable-length field and is preceded by the l
 
 An output field look like this:
 
-.A Single Output (at index 0)
+.Output Fields, Amount and ScriptPubKey. This one is at index 0.
 image::tx7.png[Output Fields]
 
 .UTXO Set
@@ -302,7 +302,7 @@ include::code-ch05/answers.py[tag=exercise3]
 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.
 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 or equal to 500,000,000, Locktime is a UNIX time stamp.
+If the Locktime is greater 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.
 

ch06.asciidoc

@@ -19,7 +19,8 @@ If you are confused about what a "smart contract" is, don't worry.
 In Bitcoin, Script is the smart contract language, or the programming language used to express the conditions under which bitcoins are spendable.
 
 Bitcoin has the digital equivalent of a contract in Script.
-Script is an intentionally limited programming language in the sense that it avoids certain features.
+Script is a stack-based language similar to Forth.
+Script is intentionally limited in the sense that Script avoids certain features.
 Specifically, Script avoids any mechanism for loops and is therefore not Turing complete.
 
 [NOTE]

ch07.asciidoc

@@ -142,7 +142,7 @@ Lastly, we add a 4-byte hash type to the end.
 This is to specify what the signature is authorizing.
 The signature can authorize that this input has to go with all the other inputs and outputs (`SIGHASH_ALL`), go with a specific output (`SIGHASH_SINGLE`) or go with any output whatsoever (`SIGHASH_NONE`).
 The latter two have some theoretical use cases, but in practice, almost every transaction is signed with `SIGHASH_ALL`.
-There's also an orthogonal hash type called `SIGHASH_ANYONECANPAY` which can be combined with any of these three, which we won't get into here.
+There's also rarely used hash type called `SIGHASH_ANYONECANPAY` which can be combined with any of the previous three, which we won't get into here.
 For `SIGHASH_ALL`, the final transaction must have the exact outputs that were signed or the input signature is invalid.
 
 The integer corresponding to `SIGHASH_ALL` is 1 and this has to be encoded in Little-Endian over 4 bytes, which makes the modified transaction look like this:
@@ -231,16 +231,17 @@ In this example, we will pay 0.1 testnet bitcoins (tBTC) to `mnrVtF8DWjMu839VW3r
 
 The second question is about what's in our wallet.
 What do we have available to spend?
-In this example, we have an output here denoted by transaction ID and output index: `0d6fe5213c0b3291f208cba8bfb59b7476dffacc4e5cb66f6eb20a080843a299:13`.
+In this example, we have an output here denoted by transaction ID and output index:
+
+`0d6fe5213c0b3291f208cba8bfb59b7476dffacc4e5cb66f6eb20a080843a299:13`
+
 When we view this output on a testnet block explorer, we can see that our output is worth 0.33 tBTC.
 
 .UTXO that we're spending
 image::txcreation1.png[Transaction seen on the blockchain]
 
 Since this is more than 0.1 tBTC, we'll want to send the rest back to ourselves.
-Though it's generally bad privacy and security practice to re-use addresses, we'll send the bitcoins back to the same address to make this step easier.
-
-`mzx5YhAH9kNHtcN481u6WkjeHjYtVeKVh2`
+Though it's generally bad privacy and security practice to reuse addresses, we'll send the bitcoins back to `mzx5YhAH9kNHtcN481u6WkjeHjYtVeKVh2` to make the transaction construction easier.
 
 .Why reusing addresses is a bad idea
 [WARNING]

ch08.asciidoc

@@ -124,7 +124,10 @@ Nodes keep track of the UTXO set, so a big ScriptPubKey is more expensive to kee
 A large output is more expensive to keep in fast-access storage (like RAM), being 5-20x larger than a normal p2pkh output.
 
 3. Third problem: because the ScriptPubKey can be so much bigger, bare multisig can and has been abused.
-The entire PDF of the Satoshi's original whitepaper is encoded in this transaction in block 230009: `54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713`.
+The entire PDF of the Satoshi's original whitepaper is encoded in this transaction in block 230009:
+
+`54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713`
+
 The creator of this transaction split up the whitepaper PDF into 64 byte chunks which were then made into invalid uncompressed public keys.
 The whitepaper was encoded into 947 outputs as 1-of-3 Bare Multisig outputs.
 These outputs are not spendable but have to be indexed in the UTXO sets of full nodes.

ch09.asciidoc

@@ -12,7 +12,7 @@ Think of Blocks as a way to order transactions.
 If we order transactions, a double-spend can be prevented by making any later, conflicting transaction invalid.
 This is the equivalent to accepting the earlier transaction as the valid one.
 
-Implement this rule would be easy (earliest transaction is valid, subsequent transactions that conflict are invalid) if we could order transactions one at a time.
+Implementing this rule would be easy (earliest transaction is valid, subsequent transactions that conflict are invalid) if we could order transactions one at a time.
 Unfortunately, that would require nodes on the network to agree on which transaction is supposed to be next and would cause a lot of transmission overhead in coming to consensus.
 We could also order large batches of transactions, maybe once per day, but that wouldn't be very practical as transactions would settle only once per day and not have finality before then.
 
@@ -201,8 +201,8 @@ We will discuss how this is important for SPV (simplified payment verification)
 The timestamp is a UNIX-style timestamp taking up 4 bytes.
 Unix timestamps are the number of seconds since January 1, 1970.
 This timestamp is used in two places.
-The first for validating timestamp-based locktimes on transactions included in the block and in calculating a new bits/target/difficulty every 2016 blocks.
-The locktimes were at one point used directly for transactions within a block, but BIP113 changed the behavior to not use the current block's Locktime directly, but the median-time-past (MTP) of the past 11 blocks.
+The first for validating timestamp-based Locktimes on transactions included in the block and in calculating a new bits/target/difficulty every 2016 blocks.
+The Locktimes were at one point used directly for transactions within a block, but BIP113 changed the behavior to not use the current block's Locktime directly, but the median-time-past (MTP) of the past 11 blocks.
 
 [NOTE]
 .Will Bitcoin overflow on the timestamp?

ch14.asciidoc

@@ -30,7 +30,7 @@ The specifications and test vectors are defined in the BIP0032 standard, so impl
 
 Additionally, BIP0044 defines what each layer of the BIP0032 hierarchy can mean and the best practices for using a single HD seed to store coins from a lot of different cryptocurrencies.
 Implementing BIP0044 can also be a way to understand the HD wallet infrastructure a lot better.
-While many wallets (Trezor, Coinomi, etc) implement both BIP0032 and BIP0044, some wallets ignore BIP0044 altogether and use their own BIP0032 hierarchy (Electrum and Airbitz being two).
+While many wallets (Trezor, Coinomi, etc) implement both BIP0032 and BIP0044, some wallets ignore BIP0044 altogether and use their own BIP0032 hierarchy (Electrum and Edge being two).
 
 ==== Mnemonic Seeds