QC2 and checklist edits

2024-11-25 01:18:18 +00:00 · 2023-11-01 11:02:42 -04:00 · 2023-11-01 11:02:42 -04:00 · 7e9339ef12
commit 7e9339ef12
parent cc8a155b5f
16 changed files with 90 additions and 93 deletions
--- a/appa_whitepaper.adoc
+++ b/appa_whitepaper.adoc
@ -1,6 +1,7 @@
 [[satoshi_whitepaper]]
 [appendix]
-== The Bitcoin Whitepaper by Satoshi Nakamoto
+== The Bitcoin Whitepaper [.keep-together]#by Satoshi Nakamoto#
 [NOTE]
 ====
--- a/appc_bips.adoc
+++ b/appc_bips.adoc
@ -2,7 +2,7 @@
 [appendix]
 == Bitcoin Improvement Proposals
-Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community, or for describing a new feature for Bitcoin or its processes or environment.
+Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community or describing a new feature for Bitcoin or its processes or environment.
 As per BIP1 _BIP Purpose and Guidelines_, there are three((("BIPs (Bitcoin Improvement Proposals)", "types of"))) kinds of BIPs:
@ -30,37 +30,37 @@ BIPs that are ((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin
 -    BIP31: The 'pong' protocol message (and the protocol version bump to 60001) has been implemented since v0.6.1 (PR #1081).
 -    BIP32: Hierarchical Deterministic Wallets has been implemented since v0.13.0 (PR #8035).
 -    BIP34: The rule that requires blocks to contain their height (number) in the coinbase input, and the introduction of version 2 blocks has been implemented since v0.7.0. The rule took effect for version 2 blocks as of block 224413 (March 5th 2013), and version 1 blocks are no longer allowed since block 227931 (March 25th 2013) (PR #1526).
-    BIP35: The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since v0.7.0 (PR #1641). As of v0.13.0, this is only available for NODE_BLOOM (BIP111) peers.
+-    BIP35: The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since v0.7.0 (PR #1641). As of v0.13.0, this is only available for +NODE_BLOOM+ (BIP111) peers.
 [role="less_space pagebreak-before"]
-    BIP37: The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth lightweight clients) has been implemented since v0.8.0 (PR #1795). Disabled by default since v0.19.0, can be enabled by the -peerbloomfilters option.
+-    BIP37: The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth lightweight clients) has been implemented since v0.8.0 (PR #1795). Disabled by default since v0.19.0, can be enabled by the +-peerbloomfilters+ option.
 -    BIP42: The bug that would have caused the subsidy schedule to resume after block 13440000 was fixed in v0.9.2 (PR #3842).
-    BIP43: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP43. (PR #16528)
+-    BIP43: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP43 (PR #16528).
-    BIP44: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP44. (PR #16528)
+-    BIP44: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP44 (PR #16528).
-    BIP49: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP49. (PR #16528)
+-    BIP49: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP49 (PR #16528).
-    BIP61: The 'reject' protocol message (and the protocol version bump to 70002) was added in v0.9.0 (PR #3185). Starting v0.17.0, whether to send reject messages can be configured with the -enablebip61 option, and support is deprecated (disabled by default) as of v0.18.0. Support was removed in v0.20.0 (PR #15437).
+-    BIP61: The 'reject' protocol message (and the protocol version bump to 70002) was added in v0.9.0 (PR #3185). Starting v0.17.0, whether to send reject messages can be configured with the ++-enablebip61++ option, and support is deprecated (disabled by default) as of v0.18.0. Support was removed in v0.20.0 (PR #15437).
-    BIP65: The CHECKLOCKTIMEVERIFY soft fork was merged in v0.12.0 (PR #6351), and backported to v0.11.2 and v0.10.4. Mempool-only CLTV was added in PR #6124.
+-    BIP65: The ++CHECKLOCKTIMEVERIFY++ soft fork was merged in v0.12.0 (PR #6351), and backported to v0.11.2 and v0.10.4. Mempool-only +CLTV+ was added in PR #6124.
 -    BIP66: The strict DER rules and associated version 3 blocks have been implemented since v0.10.0 (PR #5713).
 -    BIP68: Sequence locks have been implemented as of v0.12.1 (PR #7184), and have been buried since v0.19.0 (PR #16060).
 -    BIP70 71 72: Payment Protocol support has been available in Bitcoin Core GUI since v0.9.0 (PR #5216). Support can be optionally disabled at build time since v0.18.0 (PR 14451), and it is disabled by default at build time since v0.19.0 (PR #15584). It has been removed as of v0.20.0 (PR 17165).
 -    BIP84: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP84. (PR #16528)
 -    BIP86: Descriptor wallets by default use the Hierarchical Deterministic Wallet derivation proposed by BIP86 since v23.0 (PR #22364).
 -    BIP90: Trigger mechanism for activation of BIPs 34, 65, and 66 has been simplified to block height checks since v0.14.0 (PR #8391).
-    BIP111: NODE_BLOOM service bit added and enforced for all peer versions as of v0.13.0 (PR #6579 and PR #6641).
+-    BIP111: +NODE_BLOOM+ service bit added and enforced for all peer versions as of v0.13.0 (PR #6579 and PR #6641).
-    BIP112: The CHECKSEQUENCEVERIFY opcode has been implemented since v0.12.1 (PR #7524), and has been buried since v0.19.0 (PR #16060).
+-    BIP112: The +CHECKSEQUENCEVERIFY+ opcode has been implemented since v0.12.1 (PR #7524), and has been buried since v0.19.0 (PR #16060).
 -    BIP113: Median time past lock-time calculations have been implemented since v0.12.1 (PR #6566), and has been buried since v0.19.0 (PR #16060).
-    BIP125: Opt-in full replace-by-fee signaling partially implemented. See doc/policy/mempool-replacements.md.
+-    BIP125: Opt-in full replace-by-fee signaling partially implemented. 
-    BIP130: direct headers announcement is negotiated with peer versions >=70012 as of v0.12.0 (PR 6494).
+-    BIP130: direct headers announcement is negotiated with peer versions ≥70012 as of v0.12.0 (PR 6494).
-    BIP133: feefilter messages are respected and sent for peer versions >=70013 as of v0.13.0 (PR 7542).
+-    BIP133: feefilter messages are respected and sent for peer versions ≥70013 as of v0.13.0 (PR 7542).
 -    BIP141: Segregated Witness (Consensus Layer) as of v0.13.0 (PR 8149), defined for mainnet as of v0.13.1 (PR 8937), and buried since v0.19.0 (PR #16060).
 -    BIP143: Transaction Signature Verification for Version 0 Witness Program as of v0.13.0 (PR 8149), defined for mainnet as of v0.13.1 (PR 8937), and buried since v0.19.0 (PR #16060).
 -    BIP144: Segregated Witness as of 0.13.0 (PR 8149).
 -    BIP145: getblocktemplate updates for Segregated Witness as of v0.13.0 (PR 8149).
-    BIP147: NULLDUMMY soft fork as of v0.13.1 (PR 8636 and PR 8937), buried since v0.19.0 (PR #16060).
+-    BIP147: +NULLDUMMY+ soft fork as of v0.13.1 (PR 8636 and PR 8937), buried since v0.19.0 (PR #16060).
 -    BIP152: Compact block transfer and related optimizations are used as of v0.13.0 (PR 8068).
 -    BIP155: The 'addrv2' and 'sendaddrv2' messages which enable relay of Tor V3 addresses (and other networks) are supported as of v0.21.0 (PR 19954).
 -    BIP157 158: Compact Block Filters for Light Clients can be indexed as of v0.19.0 (PR #14121) and served to peers on the P2P network as of v0.21.0 (PR #16442).
-    BIP159: The NODE_NETWORK_LIMITED service bit is signalled as of v0.16.0 (PR 11740), and such nodes are connected to as of v0.17.0 (PR 10387).
+-    BIP159: The +NODE_NETWORK_LIMITED+ service bit is signalled as of v0.16.0 (PR 11740), and such nodes are connected to as of v0.17.0 (PR 10387).
 -    BIP173: Bech32 addresses for native Segregated Witness outputs are supported as of v0.16.0 (PR 11167). Bech32 addresses are generated by default as of v0.20.0 (PR 16884).
 -    BIP174: RPCs to operate on Partially Signed Bitcoin Transactions (PSBT) are present as of v0.17.0 (PR 13557).
 -    BIP176: Bits Denomination [QT only] is supported as of v0.16.0 (PR 12035).
@ -70,4 +70,4 @@ BIPs that are ((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin
 -    BIP350: Addresses for native v1+ segregated Witness outputs use bech32m instead of bech32 as of v22.0 (PR 20861).
 -    BIP371: Taproot fields for PSBT as of v24.0 (PR 22558).
 -    BIP380 381 382 383 384 385: Output Script Descriptors, and most of Script Expressions are implemented as of v0.17.0 (PR 13697).
-    BIP386: tr() Output Script Descriptors are implemented as((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin Core", startref="bips-implement")))((("Bitcoin Core", "BIPs implemented by", startref="bitcoin-core-bips"))) of v22.0 (PR 22051).
+-    BIP386: +tr()+ Output Script Descriptors are implemented as((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin Core", startref="bips-implement")))((("Bitcoin Core", "BIPs implemented by", startref="bitcoin-core-bips"))) of v22.0 (PR 22051).
--- a/author_bio.html
+++ b/author_bio.html
@ -9,5 +9,5 @@
 <p>As a bitcoin entrepreneur, Andreas has founded a number of Bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.</p>
-<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the coauthor of the Bitcoin Optech weekly newsletter (2018–23), 21.co Bitcoin Computer tutorials (2015–17), and Bitcoin.org developer documentation (2014–15). He is also a Brink.dev grant committee member (2022–23) and former board member (2020–22).</p>
+<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the coauthor of the Bitcoin Optech weekly newsletter (2018–2023), 21.co Bitcoin Computer tutorials (2015–2017), and Bitcoin.org developer documentation (2014–2015). He is also a Brink.dev grant committee member (2022–2023) and former board member (2020–2022).</p>
 </section>
--- a/ch03_bitcoin-core.adoc
+++ b/ch03_bitcoin-core.adoc
@ -374,7 +374,7 @@ nodes (called "peers"), consuming upload internet bandwidth. If your
 internet connection is limited, has a low data cap, or is metered
 (charged by the gigabit), you should probably not run a Bitcoin node on
 it, or run it in a way that constrains its bandwidth (see
-<<constrained_resources>>).  You may connect your node instead to an
+<<bitcoincorenode_config>>).  You may connect your node instead to an
 alternative network, such as a free satellite data provider like
 https://oreil.ly/cIwf3[Blockstream Satellite].
@ -390,7 +390,7 @@ transactions or update account balances until the full blockchain
 dataset is downloaded. Make sure you have enough disk space, bandwidth,
 and time to complete the initial synchronization. You can configure
 Bitcoin Core to reduce the size of the blockchain by discarding old
-blocks (see <<constrained_resources>>), but it will still download the
+blocks, but it will still download the
 entire dataset.
 ====
@ -423,6 +423,7 @@ If you're reading this book and interested in strong security, superior
 privacy, or developing Bitcoin software, you should be running your ((("Bitcoin Core", "nodes", "running", startref="bitcoin-core-nodes-running")))((("nodes", "running", startref="nodes-running")))((("running nodes", startref="running-nodes")))own
 node.
 [[bitcoincorenode_config]]
 === Configuring the Bitcoin Core Node
 Bitcoin Core will((("Bitcoin Core", "nodes", "configuring", id="bitcoin-core-nodes-configure")))((("nodes", "configuring", id="nodes-configure")))((("configuring", "nodes", id="configure-nodes"))) look for a
@ -813,11 +814,11 @@ returned by +getrawtransaction+ and paste it as a parameter to
 ++++
 <pre data-type="programlisting">
-$ bitcoin-cli decoderawtransaction 01000000000101eb3ae38f27191aa5f3850dc9cad0&#x21b5;
+$ bitcoin-cli decoderawtransaction 01000000000101eb3ae38f27191aa5f3850dc9cad0\
-0492b88b72404f9da135698679268041c54a0100000000ffffffff02204e00000000000022512&#x21b5;
+0492b88b72404f9da135698679268041c54a0100000000ffffffff02204e00000000000022512\
-03b41daba4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f82401000000&#x21b5;
+03b41daba4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f82401000000\
-00001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe2d8ef13ed0af21d4f&#x21b5;
+00001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe2d8ef13ed0af21d4f\
-4cb82422d6252d70324f6f4576b727b7d918e521c00b51be739df2f899c49dc267c0ad280aca6&#x21b5;
+4cb82422d6252d70324f6f4576b727b7d918e521c00b51be739df2f899c49dc267c0ad280aca6\
 dab0d2fa2b42a45182fc83e817130100000000
 </pre>
 ++++
@ -909,7 +910,7 @@ the parameter:
 ++++
 <pre data-type="programlisting">
-$ bitcoin-cli getblock 0000000000002917ed80650c6174aac8dfc46f5fe36480aaef682f&#x21b5;
+$ bitcoin-cli getblock 0000000000002917ed80650c6174aac8dfc46f5fe36480aaef682f\
 f6cd83c3ca
 </pre>
 ++++
@ -973,10 +974,9 @@ The
 and testing functions. But the whole point of an API is to access functions programmatically. In this section we
 will demonstrate accessing Bitcoin Core from another program.
-Bitcoin Core's API is a JSON-RPC interface. JSON stands for JavaScript
+Bitcoin Core's API is a JSON-RPC interface. JSON is a very convenient way to present data that
-Object Notation, and it is a very convenient way to present data that
+both humans and programs can easily read. RPC stands for remote
-both humans and programs can easily read. RPC stands for Remote
+procedure call, which means that we are calling procedures (functions)
 Procedure Call, which means that we are calling procedures (functions)
 that are remote (on the Bitcoin Core node) via a network protocol. In
 this case, the network protocol is HTTP.
@ -1168,7 +1168,7 @@ and more are created all the time.
 If you followed the instructions in this chapter, you now have Bitcoin
 Core running and have begun exploring the network and blockchain using
 your own full node.  From now on you can independently use software you
-control, on a computer you control, to verify any bitcoins you receive
+control—on a computer you control—to verify that any bitcoins you receive
 follow every rule in the Bitcoin system without having to trust any
 outside authority.  In the coming chapters, we'll learn more about the
 rules of the system and how your node and your wallet use them to secure
--- a/ch04_keys.adoc
+++ b/ch04_keys.adoc
@ -384,7 +384,7 @@ geometric operation on the curve.
 [TIP]
 ====
 Many Bitcoin implementations use
-the https://oreil.ly/wD60m[libsecp256k1 crytographic
+the https://oreil.ly/wD60m[libsecp256k1 cryptographic
 library] to do the elliptic curve((("public keys", "generating", startref="public-key-generate")))((("elliptic curve multiplication", startref="elliptic-multiply"))) math.
 ====
@ -620,7 +620,7 @@ output, causing them to be lost forever.  In the next section, we'll
 look at compact encoding and reliable ((("public key cryptography", "hash functions and", startref="pub-key-hash")))((("hash functions", "Bitcoin payments and", startref="hash-payment")))((("payments", "with hash functions", secondary-sortas="hash functions", startref="payment-hash")))((("P2PKH (pay to public key hash)", startref="p2pkh-legacy")))((("addresses", "P2PKH (pay to public key hash)", startref="address-p2pkh-legacy")))((("commitments", startref="commitment")))checksums.
 [[base58]]
-=== Base58Check Encoding
+=== Base58check Encoding
 In order((("public key cryptography", "base58check encoding", id="pub-key-base58")))((("base58check encoding", id="base58-ch4")))((("encoding", "base58check", id="encode-base58"))) to represent long numbers in a compact way,
 using fewer symbols, many computer systems use mixed-alphanumeric
@ -690,7 +690,7 @@ encoding process.
 [[base58check_encoding]]
 .Base58check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data.
-image::images/mbc3_0406.png["Base58CheckEncoding"]
+image::images/mbc3_0406.png["Base58checkEncoding"]
 ++++
 <p class="fix_tracking2">
@ -786,7 +786,7 @@ coordinate and reducing the size of the key and the space required to
 store it by 256 bits. An almost 50% reduction in size in every
 transaction adds up to a lot of data saved over time!
-Here's the public key generated by the private key we created in
+Here is the public key generated by the private key we created in
 <<public_key_derivation>>:
 ----
@ -800,8 +800,8 @@ y+:
 ++++
 <pre data-type="programlisting">
-K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A&#x21b5;
+K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A\
-07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
+    07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
 </pre>
 ++++
@ -1082,7 +1082,7 @@ The "32" stands for the number of characters in the bech32 alphabet
 - Bech32 uses only numbers and a single case of letters (preferably
  rendered in lowercase).  Despite its alphabet being almost half the
-  size of the base58check alphabet, a bech32 address for a P2WPKH script
+  size of the base58check alphabet, a bech32 address for a pay to witness public key hash (P2WPKH) script
  is only slightly longer than a legacy address for an equivalent P2PKH
  script.
@ -1331,7 +1331,7 @@ function.  The resultant 32-byte digest is then passed into a RIPEMD-160
 hash function.  The digest of that function (the commitment) is placed
 in the witness program.
-For the P2WSH output, we don't use the P2SH algorithm.  Instead we take
+For the pay to witness script hash (P2WSH) output, we don't use the P2SH algorithm.  Instead we take
 the script, pass it into a SHA256 hash function, and use the 32-byte
 digest of that function in the witness program.  For P2SH, the SHA256
 digest was hashed again with RIPEMD-160, but that may not be secure in
--- a/ch05_wallets.adoc
+++ b/ch05_wallets.adoc
@ -508,7 +508,7 @@ and automatically create complete backups of their wallet database
 encrypted by one of the keys derived from their seed.  Bitcoin keys must
 be unguessable and modern encryption algorithms are considered very
 secure, so nobody should be able to open the encrypted backup except
-someone who can generate the seed, making it safe to store the backup on
+someone who can generate the seed. This makes it safe to store the backup on
 untrusted computers such as cloud hosting services or even random
 network peers.
@ -807,7 +807,7 @@ data and the length of recovery code in((("wallets", "recovery codes", "generati
 The ((("wallets", "recovery codes", "seed generation", id="wallet-recovery-bip39-seed")))((("recovery codes", "seed generation", id="recovery-code-bip39-seed")))((("BIP39 recovery codes", "seed generation", primary-sortas="BIP039", id="bip39-recovery-seed")))((("entropy", "seed generation", id="entropy-seed-generate")))((("seeds", "generating", id="seed-generate")))((("key-stretching functions", id="key-stretch")))recovery code
 represents entropy with a length of 128 to 256 bits. The entropy is then
 used to derive a longer (512-bit) seed through the use of the
-key-stretching function PBKDF2. The seed produced is then used to build
+https://oreil.ly/6lwbd[key-stretching function PBKDF2]. The seed produced is then used to build
 a deterministic wallet and derive its keys.
 The key-stretching function takes two
@ -1061,14 +1061,14 @@ wallet is shown in <<HDWalletFromSeed>>.
 image::images/mbc3_0506.png["HDWalletFromRootSeed"]
 The root seed is input into the HMAC-SHA512 algorithm and the resulting
-hash is used to create a _master private key_ (m) and a _master chain
+hash is used to create a _master private key_ (_m_) and a _master chain
-code_ (c).
+code_ (_c_).
-The master private key (m) then generates a corresponding master public
+The master private key (_m_) then generates a corresponding master public
-key (M) using the normal elliptic curve multiplication process m × _G_
+key (_M_) using the normal elliptic curve multiplication process _m_ × _G_
 that we saw in <<public_key_derivation>>.
-The chain code (c) is used to introduce entropy in the function that
+The master chain code (_c_) is used to introduce entropy in the function that
 creates child keys from parent keys, as we will see in the next section.
 ===== Private child key derivation
@ -1385,8 +1385,8 @@ The index number ((("index numbers for hardened derivation")))used in the deriva
 easily distinguish between keys created through the normal derivation
 function versus keys derived through hardened derivation, this index
 number is split into two ranges. Index numbers between 0 and
-2^31^&#x2013;1 (0x0 to 0x7FFFFFFF) are used _only_ for normal
+2^31^ &#x2013; 1 (0x0 to 0x7FFFFFFF) are used _only_ for normal
-derivation. Index numbers between 2^31^ and 2^32^&#x2013;1 (0x80000000
+derivation. Index numbers between 2^31^ and 2^32^ &#x2013; 1 (0x80000000
 to 0xFFFFFFFF) are used _only_ for hardened derivation. Therefore, if
 the index number is less than 2^31^, the child is normal, whereas if the
 index number is equal or above 2^31^, the child is hardened.
--- a/ch07_authorization-authentication.adoc
+++ b/ch07_authorization-authentication.adoc
@ -193,7 +193,7 @@ The validation software combines the scripts:
 2 3 OP_ADD 5 OP_EQUAL
 ----
-As we saw in <<simplemath_script>>, when
+As we see in <<simplemath_script>>, when
 this script is executed, the result is +OP_TRUE+, making the transaction
 valid. Not only have we shown a valid transaction output script, but
 the resulting UTXO could be spent by anyone with the arithmetic skills
@ -242,7 +242,7 @@ a vulnerability known as the +1 OP_RETURN+ bug.  In the current
 implementation, the scripts are executed separately with the stack
 transferred between the two executions.
-First, the input script executed using the stack execution
+First, the input script is executed using the stack execution
 engine. If the input script is executed without errors and has
 no operations left over, the stack is copied and the
 output script is executed. If the result of executing the output script
@ -376,7 +376,7 @@ scripts wrapped in another structure like P2SH, P2WSH, or P2TR.
 P2SH multisignature scripts are limited by both policy and consensus to
 15 keys, allowing for up to a 15-of-15 multisignature. We will learn about
 P2SH in <<p2sh>>.   All other scripts are consensus limited to 20 keys
-per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
+per +OP_CHECKMULTISIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
 script may include multiple of those opcodes.
 [role="less_space pagebreak-before"]
@ -417,7 +417,7 @@ replicated forever. Therefore a script should look
 like this:
 ----
-OP_0 <Sign B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
+OP_0 <Sig B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
 ----
 Thus the input script actually used in multisig is not:
@ -780,7 +780,7 @@ It is important to understand the limitations of transaction lock time. The only
 In ((("transactions", "timelocks", "verifying", id="transaction-timelock-op-cltv")))((("timelocks", "verifying", id="timelock-op-cltv")))((("lock time", "verifying", id="lock-time-op-cltv")))((("OP_CLTV  script operator", id="op-cltv")))((("verifying", "lock time", id="verify-lock-time")))((("scripts", "timelocks", "verifying", id="script-timelock-verify")))December 2015, a new form of
 timelock was introduced to Bitcoin as a soft fork upgrade. Based on a
 specification in BIP65, a new script operator called
-_OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language.
+OP_CHECKLOCKTIMEVERIFY+ (+OP_CLTV+) was added to the scripting language.
 +OP_CLTV+ is a per-output timelock rather than a per-transaction timelock,
 as is the case with lock time. This allows for additional
 flexibility in the way timelocks are applied.
@ -1184,7 +1184,7 @@ account directly after he gains access to the capital account's
 transaction records.
 <<variable_timelock_multisig>> is the redeem script that Mohammed designs to achieve this (line
-number prefixed as XX).
+number have been prefixed).
 [[variable_timelock_multisig]]
 .Variable multi-signature with timelock
@ -1467,7 +1467,7 @@ backward-compatible upgrade, where _old and new clients can coexist_.
 Wallet developers independently upgraded wallet software to add
 segwit capabilities.
 Legacy P2PKH and
-P2SH continue to work for nonupgraded wallets. That leaves two
+P2SH continue to work for [.keep-together]#nonupgraded# wallets. That leaves two
 important scenarios, which are addressed in the next section:
 - Ability of a spender's wallet that is not segwit-aware to make a
@ -1962,7 +1962,7 @@ called _tapscript_.  The major differences include:
 [role="less_space pagebreak-before"]
 Scripted multisignature changes::
-  The old +OP_CHECKMULTSIG+ and +OP_CHECKMULTISIGVERIFY+ opcodes are
+  The old +OP_CHECKMULTISIG+ and +OP_CHECKMULTISIGVERIFY+ opcodes are
  removed.  Those opcodes don't combine well with one of the other
  changes in the taproot soft fork, the ability to use schnorr signatures
  with batch validation (see <<schnorr_signatures>>).  A new +OP_CHECKSIGADD+ opcode is provided
--- a/ch08_signatures.adoc
+++ b/ch08_signatures.adoc
@ -416,7 +416,7 @@ The nonce (k)::
 In step 1, ((("digital signatures", "schnorr signature algorithm", "security features")))((("schnorr signature algorithm", "security features")))Alice chooses a number that Bob doesn't
  know and can't guess and gives him the scaled form of that number,
  _kG_.  At that point, Bob also already has her public key (_xG_),
-  which is the scaled form of _x_), her private key.  That means when Bob is working on
+  which is the scaled form of _x_, her private key.  That means when Bob is working on
  the final equation (_sG_ = _kG_ + _exG_), there are two independent
  variables that Bob doesn't know (_x_ and _k_).  It's possible to use
  simple algebra to solve an equation with one unknown variable but not
@ -520,10 +520,10 @@ full commitment _hash_(_kG_ || _xG_ || _m_).
 Now that we've described each part of the BIP340 schnorr signature
 algorithm and explained what it does for us, we can define the protocol.
 Multiplication of integers are performed _modulus p_, indicating that the
-result of the operation divided by the number _p_ (as defined in the
+result of the operation is divided by the number _p_ (as defined in the
 secp256k1 standard) and the remainder is used.  The number _p_ is very
 large, but if it was 3 and the result of an operation was 5, the actual
-number we would use is 2 (i.e., 5 divided by 3 is 2).
+number we would use is 2 (i.e., 5 divided by 3 has a remainder of 2).
 Setup: Alice chooses a large random number (_x_) as her private key
 (either directly or by using a protocol like BIP32 to deterministically
@ -620,10 +620,10 @@ simple multisignature protocol:
 3. Alice produces the scalar _q_ = _a_ + _ey_.  Bob produces the scalar
   _r_ = _b_ + _ez_.  They add the scalars together to produce
-   _s_ = _q_ + _r_.  Their signature is the two values _kG_ and _s_.
+   _s_ = _q_ + _r_.  Their signature is the two values _kG_ [.keep-together]#and _s_.#
 4. The verifiers check their public key and signature using the normal
-   equation: _sG_ == _kG_ + _hash_(_kG_ || _xG_ || _m_) × _xG_.
+   equation: [.keep-together]#_sG_ ==# _kG_ + _hash_(_kG_ || _xG_ || _m_) × _xG_.
 Alice and Bob have proven that they know the sum of their private keys without
 either one of them revealing their private key to the other or anyone
--- a/ch09_fees.adoc
+++ b/ch09_fees.adoc
@ -6,11 +6,11 @@
 The digital signature we saw Alice create in <a data-type="xref" href="#c_signatures">#c_signatures</a> only
 proves that she knows her private key and that she committed to a
 transaction that pays Bob.  She can create another signature that
-instead commits to a transaction paying Carol--a transaction that spends
+instead commits to a transaction paying Carol—a transaction that spends
 the same output (bitcoins) that she used to pay Bob.  Those two
 transactions are now <em>conflicting transactions</em> because only one
 transaction spending a particular output can be included in the valid
-blockchain with the most proof of work--the blockchain that full nodes
+blockchain with the most proof of work—the blockchain that full nodes
 use to determine which keys control which bitcoins.
 </p>
 ++++
@ -39,7 +39,7 @@ previous transaction and is also an exception to several other rules
 that apply to other transactions.  Coinbase transactions don't pay
 transaction fees, don't need to be fee bumped, aren't subject to
 transaction pinning, and are largely uninteresting to the following
-discussion about fees--so we're going to ignore them in this chapter.
+discussion about fees—so we're going to ignore them in this chapter.
 </p>
 </div>
 ++++
@ -133,7 +133,7 @@ fee rates.
 Be careful ((("absurd fees")))((("excessive fees")))((("transaction fees", "overpaying")))((("overpaying transaction fees")))accepting input for fee rates.  If a user copies and pastes a
 fee rate printed in one denominator into a field using a different
 denominator, they could overpay fees by 1,000 times.  If they instead
-switch the denominator, they could theoretically overpay by 100,000,000
+switch the numerator, they could theoretically overpay by 100,000,000
 times.  Wallets should make it hard for the user to pay an excessive
 fee rate and may want to prompt the user to confirm any fee rate that was
 not generated by the wallet itself using a trusted data source.
@ -639,7 +639,7 @@ you intended.
 Fee sniping ((("transaction fees", "fee sniping", id="transaction-fee-sniping")))((("fee sniping", id="fee-snipe")))((("timelocks", "fee sniping and", id="timelock-fee-snipe")))((("lock time", "fee sniping and", id="lock-time-fee-snipe")))is a theoretical
 attack scenario where miners attempting to rewrite past blocks "snipe"
 higher-fee transactions from future blocks to maximize their
-profitability.
+[.keep-together]#profitability.#
 For example, let's say the highest block in existence is block
 #100,000. If instead of attempting to mine block #100,001 to extend the
--- a/ch10_network.adoc
+++ b/ch10_network.adoc
@ -523,7 +523,7 @@ both tourists can verify the existence of a street by visiting it, the
 tourist without a map doesn't know what lies down any of the side
 streets and doesn't know what other streets exist. Positioned in front
 of 23 Church Street, the tourist without a map cannot know if there are
-a dozen other "23 Church Street" addresses in the city and whether this
+a dozen other [.keep-together]#"23 Church# Street" addresses in the city and whether this
 is the right one. The mapless tourist's best chance is to ask enough
 people and hope some of them are not trying to mug him.
@ -720,7 +720,7 @@ pattern is definitely((("Bitcoin network", "bloom filters", "operational overvie
 .Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!"
 image::images/mbc3_1010.png[]
-=== How Lightweight Clients Use Bloom Filters
+==== How Lightweight Clients Use Bloom Filters
 Bloom filters ((("Bitcoin network", "bloom filters", "lightweight clients and", id="bitcoin-network-bloom-lightweight")))((("bloom filters", "lightweight clients and", id="bloom-lightweight")))((("lightweight clients", "bloom filters and", id="lightweight-bloom")))are used to filter the transactions (and blocks containing
 them) that a lightweight client receives from its peers, selecting only
@ -1170,8 +1170,6 @@ As a way to increase the privacy and security of the Bitcoin P2P
 network, there is a solution that provides encryption of the
 communications: _Tor transport_.
 ==== Tor Transport
 Tor, which
 stands for _The Onion Routing network_, is a software project and
 network that offers encryption and encapsulation of data through
--- a/ch11_blockchain.adoc
+++ b/ch11_blockchain.adoc
@ -6,7 +6,7 @@ It's what allows every full node to independently determine what keys and
 scripts control which bitcoins.  In this chapter, we'll look at the
 structure of the blockchain and see how it uses cryptographic
 commitments and other clever tricks to make every part of it easy for
-full nodes (and sometimes light clients) to validate.
+full nodes (and sometimes lightweight clients) to validate.
 The blockchain data structure is
 an ordered, back-linked list of blocks of transactions.  The blockchain
@ -382,7 +382,7 @@ Bitcoin's merkle trees is SHA256 applied twice, also known as
 double-SHA256.
 When N data elements are hashed and summarized in a merkle tree, you can
-check to see if any one data element is included in the tree with at
+check to see if any one data element is included in the tree with 
 about +log~2~(N)+ calculations, making this a very efficient data
 structure.
@ -812,7 +812,7 @@ $ bitcoin-cli -regtest generatetoaddress 500 \
 It will only take a few seconds to mine all these blocks, which
 certainly makes it easy for testing. If you check your wallet balance,
-you will see that you earned a reward for the first 400 blocks (coinbase
+you will see that you earned the rewards for the first 400 blocks (coinbase
 rewards must be 100 blocks deep before you can ((("blockchain", "test blockchains", "regtest", startref="blockchain-test-regtest")))((("test blockchains", "regtest", startref="test-block-regtest")))((("regtest", startref="regtest")))spend them):
 ----
@ -826,7 +826,7 @@ Bitcoin's ((("blockchain", "test blockchains", "development usage")))((("test bl
 blockchains (regtest, signet, testnet3, mainnet) offer a range
 of testing environments for bitcoin development. Use the test
 blockchains whether you are developing for Bitcoin Core or another
-full-node consensus client (an application such as a wallet, exchange,
+full-node consensus client; an application such as a wallet, exchange,
 ecommerce site; or even developing novel smart contracts and complex
 scripts).
--- a/ch12_mining.adoc
+++ b/ch12_mining.adoc
@ -167,8 +167,7 @@ The most ((("deflation", id="deflation")))((("inflation", id="inflation")))impor
 fixed and diminishing monetary issuance is that the currency tends to be
 inherently _deflationary_. Deflation is the phenomenon of appreciation
 of value due to a mismatch in supply and demand that drives up the value
-(and exchange rate) of a currency. The opposite of inflation, price
+(and exchange rate) of a currency. Price deflation is the opposite of inflation; it means that the money has more purchasing power over time.
 deflation, means that the money has more purchasing power over time.
 Many economists argue that a deflationary economy is a disaster that
 should be avoided at all costs. That is because in a period of rapid
@ -947,7 +946,7 @@ New Target = Old Target * (20,160 minutes / Actual Time of Last 2015 Blocks)
 [NOTE]
 ====
 While the target calibration happens every 2,016 blocks, because of an
-off-by-one error in the original Bitcoin software it is based on the
+off-by-one error in the original Bitcoin software, it is based on the
 total time of the previous 2,015 blocks (not 2,016 as it should be),
 resulting in a retargeting bias toward higher difficulty by 0.05%.
 ====
@ -1397,8 +1396,7 @@ eight-or-less wasn't winning, it was a fair way to measure dice throws
 for the players, and it occasionally produces a less-than-four throw.
 Similarly, a mining pool will set a (higher and easier) pool target that
-will ensure that an individual pool miner can find block header hashes
+will ensure that an individual pool miner frequently earns shares by finding block header hashes that are less than the pool target. Every now and
 that are less than the pool target often, earning shares. Every now and
 then, one of these attempts will produce a block header hash that is
 less than the Bitcoin network target, making it a valid block and the
 whole pool wins.
@ -2015,7 +2013,7 @@ a different bit, renewing the activation period.
 Furthermore, after the +TIMEOUT+ has passed and a feature has been
 activated or rejected, the signaling bit can be reused for another
 feature without confusion. Therefore, up to 29 changes can be signaled
-in parallel and after +TIMEOUT+, the bits can be "recycled" to propose
+in parallel. After +TIMEOUT+, the bits can be "recycled" to propose
 new changes.
 [NOTE]
--- a/ch14_applications.adoc
+++ b/ch14_applications.adoc
@ -145,7 +145,7 @@ intrinsic to the blockchain.
 Colored coins are used to track digital
 assets as well as physical assets held by third parties and traded
-through colored coins certificates of ownership. Digital asset colored
+through certificates of ownership associated with colored coins. Digital asset colored
 coins can represent intangible assets such as a stock certificate,
 license, virtual property (game items), or most any form of licensed
 intellectual property (trademarks, copyrights, etc.). Tangible asset
@ -340,7 +340,7 @@ Translated forwarding::
  support forwarding bitcoin [.keep-together]#payments.#
 Native forwarding is conceptually simpler but essentially requires a
-separate LN for every asset.  Translated forwarding
+separate Lightning-type network for every asset.  Translated forwarding
 allows building on the economies of scale of the Bitcoin LN, but it may be vulnerable to a problem called((("free American call option"))) the _free American
 call option_, where a receiver may selectively accept or reject certain
 payments depending on recent changes to the exchange rate in order to
@ -1038,7 +1038,7 @@ efficient route.
 Alice's node then constructs an HTLC, payable to the hash +H+, with a
 10-block refund timeout (current block + 10), for an amount of 1.003
-bitcoins (see <<ln_payment_process>> step 2). The extra 0.003 will be
+bitcoins (see <<ln_payment_process>>, step 2). The extra 0.003 will be
 used to compensate the intermediate nodes for their participation in
 this payment route. Alice offers this HTLC to Bob, deducting 1.003
 bitcoins from her channel balance with Bob and committing it to the HTLC.
@ -1068,7 +1068,7 @@ Carol now has a commitment that if she gets +R+ within the next nine
 blocks, she can claim 1.002 bitcoins locked by Bob. Now she can make an
 HTLC commitment on her channel with Diana. She commits an HTLC of 1.001
 bitcoins to hash +H+, for eight blocks, which Diana can redeem if she has
-secret +R+ (see <<ln_payment_process>> step 4). From Carol's
+secret +R+ (see <<ln_payment_process>>, step 4). From Carol's
 perspective, if this works she is 0.001 bitcoins better off and if it
 doesn't she loses nothing. Her HTLC to Diana is only viable if +R+ is
 revealed, at which point she can claim the HTLC from Bob. The channel
@ -1076,27 +1076,27 @@ balance between Carol and Diana is now: 2 to Diana, 0.999 to Carol,
 1.001 committed by Carol to the HTLC.
 Finally, Diana can offer an HTLC to Eric, committing 1 bitcoin for seven
-blocks to hash +H+ (see <<ln_payment_process>> step 5). The channel
+blocks to hash +H+ (see <<ln_payment_process>>, step 5). The channel
 balance between Diana and Eric is now: 2 to Eric, 1 to Diana, 1
 committed by Diana to the HTLC.
 However, at this hop in the route, Eric _has_ secret +R+. He can
 therefore claim the HTLC offered by Diana. He sends +R+ to Diana and
 claims the 1 bitcoin, adding it to his channel balance (see
-<<ln_payment_process>> step 6). The channel balance is now: 1 to Diana,
+<<ln_payment_process>>, step 6). The channel balance is now: 1 to Diana,
 3 to Eric.
 Now, Diana has secret +R+. Therefore, she can now claim the HTLC from
 Carol. Diana transmits +R+ to Carol and adds the 1.001 bitcoins to her
-channel balance (see <<ln_payment_process>> step 7). Now the channel
+channel balance (see <<ln_payment_process>>, step 7). Now the channel
 balance between Carol and Diana is: 0.999 to Carol, 3.001 to Diana.
 Diana has "earned" 0.001 for participating in this payment route.
 Flowing back through the route, the secret +R+ allows each participant
 to claim the outstanding HTLCs. Carol claims 1.002 from Bob, setting the
 balance on their channel to: 0.998 to Bob, 3.002 to Carol (see
-<<ln_payment_process>> step 8). Finally, Bob claims the HTLC from Alice
+<<ln_payment_process>>, step 8). Finally, Bob claims the HTLC from Alice
-(see <<ln_payment_process>> step 9). Their channel balance is updated
+(see <<ln_payment_process>>, step 9). Their channel balance is updated
 as: 0.997 to Alice, 3.003 to Bob.
 Alice has paid Eric 1 bitcoin without opening a channel to Eric. None of
--- a/colo.html
+++ b/colo.html
@ -10,5 +10,5 @@
 <p>Many of the animals on O'Reilly covers are endangered; all of them are important to the world. To learn more about how you can help, go to <a class="orm:hideurl" href="https://animals.oreilly.com"><em>animals.oreilly.com</em></a>.</p>
-<p>The cover image is from <em>Insects Abroad</em>. The cover fonts are URW Typewriter and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.</p>
+<p>The cover illustration is by Karen Montgomery, based on an image from <em>Insects Abroad</em>. The cover fonts are Gilroy Semibold and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.</p>
 </section>
--- a/meta/third_edition_changes.asciidoc
+++ b/meta/third_edition_changes.asciidoc
@ -12,7 +12,7 @@ development in 2023 have been added.
 Old Chapters 6 and 7::
  Text from previous versions of Chapter 6, "Transactions," and Chapter 7,
  "Advanced Transactions," has been rearranged and expanded across four
-  new chapters:  pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_transactions">#c_transactions</a>]  (the structure of txes), pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_authorization_authentication">#c_authorization_authentication</a>], pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_signatures">#c_signatures</a>], and
+  new chapters:  pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_transactions">#c_transactions</a>]  (the structure of transactions), pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_authorization_authentication">#c_authorization_authentication</a>], pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_signatures">#c_signatures</a>], and
   pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#tx_fees">#tx_fees</a>].
 <<c_transactions>>::
--- a/preface.asciidoc
+++ b/preface.asciidoc
@ -169,7 +169,7 @@ During the development of the book, I made early drafts available on GitHub and
 Once the book was drafted, it went through several rounds of technical review. Thanks to Cricket Liu and Lorne Lantz for their thorough review, comments, and support.
-Several Bitcoin developers contributed code samples, reviews, comments, and encouragement. Thanks to Amir Taaki and Eric Voskuil for example code snippets and many great comments; Chris Kleeschulte for contributing the Bitcore appendix; Vitalik Buterin and Richard Kiss for help with elliptic curve math and code contributions; Gavin Andresen for corrections, comments, and encouragement; Michalis Kargakis for comments, contributions, and btcd writeup; and Robin Inge for errata submissions improving the second print. In the second edition, I again received a lot of help from many Bitcoin Core developers, including Eric Lombrozo who demystified segregated witness, Luke Dashjr who helped improve the chapter on transactions, Johnson Lau who reviewed segregated witness and other chapters, and many others. I owe thanks to Joseph Poon, Tadge Dryja, and Olaoluwa Osuntokun who explained Lightning Network, reviewed my writing, and answered questions when I got stuck.
+Several Bitcoin developers contributed code samples, reviews, comments, and encouragement. Thanks to Amir Taaki and Eric Voskuil for example code snippets and many great comments; Chris Kleeschulte for contributing information about Bitcore; Vitalik Buterin and Richard Kiss for help with elliptic curve math and code contributions; Gavin Andresen for corrections, comments, and encouragement; Michalis Kargakis for comments, contributions, and btcd writeup; and Robin Inge for errata submissions improving the second print. In the second edition, I again received a lot of help from many Bitcoin Core developers, including Eric Lombrozo who demystified segregated witness, Luke Dashjr who helped improve the chapter on transactions, Johnson Lau who reviewed segregated witness and other chapters, and many others. I owe thanks to Joseph Poon, Tadge Dryja, and Olaoluwa Osuntokun who explained Lightning Network, reviewed my writing, and answered questions when I got stuck.
 I owe my love of words and books to my mother, Theresa, who raised me in a house with books lining every wall. My mother also bought me my first computer in 1982, despite being a self-described technophobe. My father, Menelaos, a civil engineer who just published his first book at 80 years old, was the one who taught me logical and analytical thinking and a love of science and engineering.