All: edits for follow-up feedback from Murchandamus (thanks!)

ch08.asciidoc

@@ -568,7 +568,7 @@ when the transaction does not in fact exist. The lightweight client establishes
 the existence of a transaction in a block by requesting a merkle path
 proof and by validating the Proof-of-Work in the chain of blocks.
 However, a transaction's existence can be "hidden" from a lightweight client. A
-lightweight client can definitely prove that a transaction exists but cannot
+lightweight client can definitely verify that a transaction exists but cannot
 verify that a transaction, such as a double-spend of the same UTXO,
 doesn't exist because it doesn't have a record of all transactions. This
 vulnerability can be used in a denial-of-service attack or for a
@@ -1140,7 +1140,7 @@ node downloads all transactions and therefore reveals no information
 about whether it is using some address in its wallet. A lightweight client
 only downloads transactions that are related to its wallet in some way.
 
-Bloom filters and compact block filters are a way to reduce the loss of privacy. Without them, a
+Bloom filters and compact block filters are ways to reduce the loss of privacy. Without them, a
 lightweight client would have to explicitly list the addresses it was interested
 in, creating a serious breach of privacy. However, even with
 filters, an adversary monitoring the traffic of a lightweight client or

ch09.asciidoc

@@ -490,7 +490,7 @@ bloom filter, it will send that block using a +merkleblock+ message. The
 +merkleblock+ message contains the block header as well as a merkle path
 that links the transaction of interest to the merkle root in the block.
 The lightweight client can use this merkle path to connect the transaction to the
-block and verify that the transaction is included in the block. The lightweight
+block header and verify that the transaction is included in the block. The lightweight
 client also uses the block header to link the block to the rest of the
 blockchain. The combination of these two links, between the transaction
 and block, and between the block and blockchain, proves that the

ch10.asciidoc

@@ -609,7 +609,7 @@ step is to commit to all the transactions using merkle trees.  Each
 transaction is listed using its witness transaction identifier (_wtxid_)
 in topographical order, with 32 0x00 bytes standing in for the wtxid of
 the first transaction (the coinbase).  As we saw in the <<merkle_trees>>
-the last wtxid is duplicated if there are an odd number of wtxids,
+the last wtxid is hashed with itslef if there are an odd number of wtxids,
 creating nodes that each containing the hash of one transaction. The
 transaction hashes are then combined, in pairs, creating each level of
 the tree, until all the transactions are summarized into one node at the
@@ -643,7 +643,7 @@ The final field is the nonce, which is initialized to zero.
 
 With all the other fields filled, the header of the candidate block is now complete and
 the process of mining can begin. The goal is now to find a header
-that results in its hash that is less than the target.
+that results in a hash that is less than the target.
 The mining node will need to test billions or trillions of variations of
 the header before a version is found that satisfies the requirement.
 
@@ -1454,7 +1454,7 @@ consensus mechanism so as to disrupt the security and availability of
 the Bitcoin network.
 
 It is important to note that consensus attacks have the greatest effect on future
-consensus. Confirmed transactions ont he best blockchain
+consensus. Confirmed transactions on the best blockchain
  become more and more immutable as time passes. While in theory,
 a fork can be achieved at any depth, in practice, the computing power
 needed to force a very deep fork is immense, making old blocks

ch11.asciidoc

@@ -216,7 +216,7 @@ stick.
 ((("hardware
 signing devices")))In the long term, Bitcoin security may increasingly take the
 form of tamper-proof hardware signing devices. Unlike a smartphone or desktop
-computer, a Bitcoin hardware signing device only needs hold keys and
+computer, a Bitcoin hardware signing device only needs to hold keys and
 use them to generate signatures.  Without general-purpose software to
 compromise and
 with limited interfaces, hardware signing devices can deliver an almost

ch12.asciidoc

@@ -63,7 +63,7 @@ Nonexpiration:: A valid transaction does not expire. If it is valid
 today, it will be valid in the near future, as long as the inputs remain
 unspent and the consensus rules do not change.
 
-Integrity:: A Bitcoin transaction signed with +SIGHASH_ALL+ or parts of
+Integrity:: The outputs of Bitcoin transaction signed with +SIGHASH_ALL+ or parts of
 a transaction signed by another +SIGHASH+ type cannot be modified
 without invalidating the signature, thus invalidating the transaction
 itself.
@@ -710,7 +710,7 @@ id="PSCaymetric12")))Another way to handle the prior commitment states
 is to explicitly revoke them. However, this is not easy to achieve. A
 key characteristic of Bitcoin is that once a transaction is valid, it
 remains valid and does not expire. The only way to cancel a transaction
-is to get a conflicting transactionn confirmed.
+is to get a conflicting transaction confirmed.
 That's why we used timelocks in the simple payment channel
 example above to ensure that more recent commitments could be spent
 before older commitments were valid. However, sequencing commitments in

chapters/authorization-authentication.adoc

@@ -324,9 +324,8 @@ scripts")))((("transactions", "advanced", id="Tadv07")))((("scripting",
 "multisignature scripts", id="Smulti07")))((("multisignature
 scripts")))Multisignature scripts set a condition where _k_ public keys
 are recorded in the script and at least _t_ of those must provide
-signatures to spend the funds. This is also known as a "M-of-N" scheme,
-where M is the total number of keys and N is the threshold of signatures
-required for validation. For example, a 2-of-3 multisignature is one
+signatures to spend the funds, called t-of-k.
+For example, a 2-of-3 multisignature is one
 where three public keys are listed as potential signers and at least two
 of those must be used to create signatures for a valid transaction to
 spend the funds.
@@ -1233,7 +1232,7 @@ number prefixed as XX):
 03      2
 04    OP_ELSE
 05      <30 days> OP_CHECKSEQUENCEVERIFY OP_DROP
-06      <Abdul the Lawyer's Pubkey> OP_CHECKSIG
+06      <Abdul the Lawyer's Pubkey> OP_CHECKSIGVERIFY
 07      1
 08    OP_ENDIF
 09    <Mohammed's Pubkey> <Saeed's Pubkey> <Zaira's Pubkey> 3 OP_CHECKMULTISIG

chapters/errata.adoc

@@ -1,3 +1,4 @@
+[appendix]
 == Errata to the Bitcoin Whitepaper
 
 A description of known problems in Satoshi Nakamoto’s paper, "Bitcoin:
@@ -6,8 +7,8 @@ changes and how Bitcoin's implementation differs from that described in
 the paper.
 
 This document was originally published by a co-author of this book in
-2016; it is reproduced here with updates.  The numbers and names of
-sections in this errata correspond to the numbers and names of the
+2016; it is reproduced here with updates.  The names of
+sections in this errata correspond to the names of the
 sections in Nakamoto's original paper.
 
 === Abstract
@@ -23,7 +24,7 @@ longest chain would be the one backed by the largest pool of
 computational power. However, Bitcoin was implemented in such a way that
 the amount of POW can vary between blocks, so it became important not to
 check for the "the longest chain" but rather "the chain demonstrating
-the most POW"; this is often shortened to "strongest chain".
+the most POW"; this is often shortened to "most-work chain".
 +
 The
 https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420[change]
@@ -68,7 +69,8 @@ paper which refer to "network nodes" is mainly about what nodes can do
 even if they aren’t mining.
 * *Post-publication discovery:* When a new block is produced, the miner
 who produces that block can begin working on its sequel immediately but
-all other miners must wait for that new block to propagate across the
+all other miners are unaware of the new block and cannot begin working
+on it until it has propagated across the
 network to them. This gives miners who produce many blocks an edge over
 miners who produce fewer blocks, and this can be exploited in what’s
 known as the _selfish mining attack_ to allow an attacker with around
@@ -186,8 +188,9 @@ Some linking is still unavoidable with multi-input transactions, which
 necessarily reveal that their inputs were owned by the same owner
 ____
 
-* *Post-publication invention:* the revelation of a common owner for
-different inputs isn’t necessary if owners often mix their inputs with
+* *Post-publication invention:* it isn't clear that different inputs
+in the same transaction have the same owner if if owners often mix their
+inputs with
 inputs belonging to other owners. For example, there’s no public
 difference between Alice and Bob each contributing one of their inputs
 towards paying Charlie and Dan than there is between just Alice

chapters/fees.adoc

@@ -113,10 +113,10 @@ different units:
 
 - BTC/Bytes (a legacy unit rarely used anymore)
 - BTC/Kilobytes (a legacy unit rarely used anymore)
-- BTC/vbytes (rarely used)
+- BTC/Vbytes (rarely used)
 - BTC/Kilo-vbyte (used mainly in Bitcoin Core)
-- Satoshi/vbyte (most commonly used today)
-- Satoshi/weight (also commonly used today)
+- Satoshi/Vbyte (most commonly used today)
+- Satoshi/Weight (also commonly used today)
 
 We recommend either the sat/vbyte or sat/weight units for displaying
 fee rates.
@@ -560,7 +560,7 @@ uses her output to attach either 25 child transactions or any smaller
 number of child transactions equaling 100,000 vbytes in size.  Without
 carve-out, Bob would be unable to attach another child transaction to
 his output for CPFP fee bumping.  With carve-out, he can spend one of
-the two outputs in the transaction, the one that belongs to me, as long
+the two outputs in the transaction, the one that belongs to him, as long
 as his child transaction is less than 1,000 vbytes in size (which should
 be more than enough space).
 

chapters/signatures.adoc

@@ -664,7 +664,7 @@ Everyone with a partial public key that becomes part of the aggregated
 public key must contribute a partial signature and partial nonce to the
 final signature.  Sometimes, though, the participants want to allow a
 subset of them to sign, such as t-of-k where a threshold (t) number of participants can sign for
-a key constructed by n participants.  That type of signature is called a
+a key constructed by k participants.  That type of signature is called a
 _threshold signature_.
 
 We saw script-based threshold signatures in