PR and QC1

appb_errata.adoc

@@ -19,7 +19,7 @@ witnessed, but proof that it came from the largest pool of CPU power."
 ____
 
 * *Implementation detail:* If each link in the chain (called "blocks"
-in Bitcoin) was built using the same amount of proof of work (PoW), the
+in Bitcoin) was built using the same amount of _proof of work_ (PoW), the
 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
@@ -37,7 +37,7 @@ occurred in July 2010, long after Bitcoin’s initial release:
 +    if (pindexNew->bnChainWork > bnBestChainWork)
 ----
 * *Terminology change:* General CPUs were used to generate the POW for
-the earliest Bitcoin blocks but POW generation today is mostly performed
+the earliest Bitcoin blocks, but POW generation today is mostly performed
 by specialist Application Specific Integrated Circuits (ASICs), so
 instead of saying "CPU power" it is perhaps more correct to say
 "computational power" or, simply, "hash rate" for the hashing used
@@ -56,7 +56,7 @@ called "miners" based on Nakamoto’s analogy to gold miners in section
 6 of the paper. Nakamoto expected all miners to be nodes but the
 software he released did not require all nodes to be miners. In the
 original software, a simple menu item in the node GUI allowed toggling
-the mining function or or off.
+the mining function on or off.
 +
 Today it is the case that the overwhelming number of nodes are not
 miners and that many individuals who own mining hardware do not use it
@@ -77,7 +77,7 @@ known as the _selfish mining attack_ to allow an attacker with around
 30% of total network hash rate to make other miners less profitable,
 perhaps driving them into following the attacking miner’s policy. So
 instead of saying "a majority of CPU power is controlled by nodes that
-are not cooperating to attack the network" it is perhaps more correct
+are not cooperating to attack the network," it is perhaps more correct
 to say "as long as nodes cooperating to attack the network control less
 than about 30% of the network."
 
@@ -94,11 +94,11 @@ ____
 this system where digital signatures are not used directly but rather a
 "deterministic expression" is used instead. Just as a signature that
 matches a known public key can be used to enable a payment, the data
-that satisfies an known expression can also enable a payment.
+that satisfies a known expression can also enable a payment.
 Generically, the expression that must be satisfied in Bitcoin in order
 to spend a coin is known as an "encumbrance." Almost all encumbrances
 in Bitcoin to date require providing at least one signature. So instead
-of saying "a chain of digital signatures" it is more correct to say
+of saying "a chain of digital signatures," it is more correct to say
 "a chain of encumbrances." Given that transactions often have more
 than one input and more than one output, the structure is not very
 chain-like; it’s more accurately described as a directed acyclic ((("transactions", "errata in Bitcoin whitepaper", startref="transaction-errata")))graph
@@ -185,7 +185,7 @@ the past.
 
 ____
 "Some linking((("privacy", "errata in Bitcoin whitepaper"))) is still unavoidable with multi-input transactions, which
-necessarily reveal that their inputs were owned by the same owner"
+necessarily reveal that their inputs were owned by the same owner."
 ____
 
 * *Post-publication invention:* It isn't clear that different inputs
@@ -197,7 +197,7 @@ toward paying Charlie and Dan than there is between just Alice
 contributing two of her inputs toward paying Charlie and Dan.
 +
 This technique is known today as
-https://oreil.ly/UBEJX[CoinJoin] and software implementing
+https://oreil.ly/UBEJX[CoinJoin], and software implementing
 it has been in use since 2015.
 
 === Calculations

appc_bips.adoc

@@ -7,8 +7,8 @@ Bitcoin Improvement Proposals are design documents providing information to the
 As per BIP1 _BIP Purpose and Guidelines_, there are three((("Bitcoin Improvement Proposals (BIPs)", "types of"))) kinds of BIPs:
 
 _Standard_ BIP:: Describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
-_Informational_ BIP:: Describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice.
-_Process_ BIP:: Describes a Bitcoin process, or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation, but not to Bitcoin's codebase; they often require community consensus; and unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a process BIP.
+_Informational_ BIP:: Describes a Bitcoin design issue or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice.
+_Process_ BIP:: Describes a Bitcoin process or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation but not to Bitcoin's codebase; they often require community consensus. Unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a process BIP.
 
 BIPs are recorded in a https://oreil.ly/jjO0R[versioned repository on GitHub].
 An MIT-licensed document from the open source Bitcoin Core project,
@@ -18,7 +18,7 @@ significantly changed.
 
 BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin Core", id="bips-implement")))((("Bitcoin Core", "BIPs implemented by", id="bitcoin-core-bips")))implemented by Bitcoin Core:
 
--    BIP9: The changes allowing multiple soft-forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575)
+-    BIP9: The changes allowing multiple soft-forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575).
 -    BIP11: Multisig outputs are standard since v0.6.0 (PR #669).
 -    BIP13: The address format for P2SH addresses has been implemented since v0.6.0 (PR #669).
 -    BIP14: The subversion string is being used as User Agent since v0.6.0 (PR #669).
@@ -44,7 +44,7 @@ BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin
 -    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).
 -    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.

author_bio.html

@@ -5,7 +5,7 @@
 
 <p>Andreas grew up with the internet, starting his first company, an early BBS and proto-ISP, as a teenager in his home in Greece. He earned degrees in computer science, data communications, and distributed systems from University College London (UCL)—recently ranked among the world’s top 10 universities. After moving to the United States, Andreas cofounded and managed a successful technology research company, and in that role advised dozens of Fortune 500 company executives on networking, security, data centers, and cloud computing. More than 200 of his articles on security, cloud computing, and data centers have been published in print and syndicated worldwide. He holds two patents in networking and security.</p>
 
-<p>In 1990, Andreas started teaching various IT topics in private, professional, and academic environments. He honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than 400 speaking engagements under his belt he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a masters degree in digital currency. In this role, he helped develop the curriculum and cotaught the Introduction to Digital Currencies course, offered as a massive open online course (MOOC) through the university.</p>
+<p>In 1990, Andreas started teaching various IT topics in private, professional, and academic environments. He honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than 400 speaking engagements under his belt, he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a masters degree in digital currency. In this role, he helped develop the curriculum and cotaught the Introduction to Digital Currencies course, offered as a massive open online course (MOOC) through the university.</p>
 
 <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>
 

ch01_intro.adoc

@@ -83,9 +83,9 @@ In this chapter we'll get started by explaining some of the main concepts and te
 
 The ((("digital currencies, history of")))((("history", "of digital currencies", secondary-sortas="digital currencies")))((("cryptography")))emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are:
 
-1.     Can I trust that the money is authentic and not counterfeit?
-2.     Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
-3.     Can I be sure that no one else can claim this money belongs to them and not me?
+*     Can I trust that the money is authentic and not counterfeit?
+*     Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
+*     Can I be sure that no one else can claim this money belongs to them and not me?
 
 Issuers of paper money are constantly battling the counterfeiting problem by using increasingly sophisticated papers and printing technology.  Physical money addresses the double-spend issue easily because the same paper note cannot be in two places at once. Of course, conventional money is also often stored and transmitted digitally. In these cases, the counterfeiting and double-spend issues are handled by clearing all electronic transactions through central authorities that have a global view of the currency in circulation. For digital money, which cannot take advantage of esoteric inks or holographic strips, cryptography provides the basis for trusting the legitimacy of a user’s claim to value.  Specifically, cryptographic digital signatures enable a user to sign a digital asset or transaction proving the ownership of that asset. With the appropriate architecture, digital signatures also can be used to address the double-spend issue.
 
@@ -99,7 +99,7 @@ Although these earlier digital currencies worked, they were centralized and, as
 
 Bitcoin was((("Bitcoin", "history of")))((("history", "of Bitcoin", secondary-sortas="Bitcoin")))((("Nakamoto, Satoshi"))) first described in 2008 with the publication of a
 paper titled "Bitcoin: A Peer-to-Peer Electronic Cash
-System,"footnote:[https://oreil.ly/KUaBM["Bitcoin: A Peer-to-Peer Electronic Cash System,"]
+System,"footnote:[https://oreil.ly/KUaBM["Bitcoin: A Peer-to-Peer Electronic Cash System"],
 Satoshi Nakamoto.] written under the
 alias of Satoshi Nakamoto (see <<satoshi_whitepaper>>). Nakamoto
 combined several prior inventions such as digital signatures and Hashcash to create
@@ -153,12 +153,12 @@ derived from the original implementation written by Satoshi Nakamoto.
 
 ==== Choosing a Bitcoin Wallet
 
-Bitcoin wallets ((("wallets", "choosing")))((("selecting", "wallets")))((("choosing", see="selecting")))are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs.
+Bitcoin wallets ((("wallets", "choosing")))((("selecting", "wallets")))((("choosing", see="selecting")))are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore, it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs.
 
 ===== Types of Bitcoin wallets
 Bitcoin wallets ((("wallets", "types of", id="wallet-type")))can be categorized as follows, according to the platform:
 
-Desktop wallet:: A ((("desktop wallets")))desktop wallet was the first type of Bitcoin wallet created as a reference implementation and many users run desktop wallets for the features, autonomy, and control they offer. Running on general-use operating systems such as Windows and macOS has certain security disadvantages, however, as these platforms are often insecure and poorly configured.
+Desktop wallet:: A ((("desktop wallets")))desktop wallet was the first type of Bitcoin wallet created as a reference implementation. Many users run desktop wallets for the features, autonomy, and control they offer. Running on general-use operating systems such as Windows and macOS has certain security disadvantages, however, as these platforms are often insecure and poorly configured.
 
 Mobile wallet:: A ((("mobile wallets")))mobile wallet is the most common type of Bitcoin
 wallet. Running on smart-phone operating systems such as Apple iOS and
@@ -212,7 +212,7 @@ creates outgoing transactions.
 
 Third-party API client:: A third-party
 API client ((("third-party API clients")))is one that interacts with Bitcoin through a third-party
-system of APIs, rather than by
+system of APIs rather than by
 connecting to the Bitcoin network directly. The wallet may be stored by
 the user or by third-party servers, but the client trusts the remote
 server to provide it with accurate information and protect its ((("wallets", "types of", startref="wallet-type")))privacy.
@@ -242,9 +242,7 @@ ultimately controls your funds on your behalf. Key management software falls int
 important categories based on control: _wallets_, where you
 control the keys, and the funds and accounts with custodians where some
 third-party controls the keys. To emphasize this point, I (Andreas)
-coined the phrase:
-
-_Your keys, your coins. Not your keys, not your coins_.
+coined the phrase: _Your keys, your coins. Not your keys, not your coins_.
 
 Combining these categorizations, many Bitcoin wallets fall into a few
 groups, with the three most common being desktop full node
@@ -275,8 +273,8 @@ to restore her wallet.
 [[recovery_code_intro]]
 ==== Recovery Codes
 
-Most ((("wallets", "recovery codes", id="wallet-recovery")))((("recovery codes", id="recovery-code")))((("backing up", "recovery codes", see="recovery codes")))modern noncustodial Bitcoin wallets will provide a _recovery
-code_ for their user
+Most ((("wallets", "recovery codes", id="wallet-recovery")))((("recovery codes", id="recovery-code")))((("backing up", "recovery codes", see="recovery codes")))modern noncustodial Bitcoin wallets will provide a recovery
+code for their user
 to back up.  The recovery code usually consists of numbers, letters, or words
 selected randomly by the software, and is used as the basis for the keys
 that are generated by the wallet. See <<recovery_code_sample>> for
@@ -384,7 +382,7 @@ payment.
 Alice((("bitcoins", "receiving")))((("receiving bitcoins"))) uses the _Receive_ button, which displays a QR code, shown in <<wallet_receive>>.
 
 [[wallet_receive]]
-.Alice uses the Receive screen on her mobile Bitcoin wallet, and displays her address in a QR code format
+.Alice uses the Receive screen on her mobile Bitcoin wallet and displays her address in a QR code format
 image::images/mbc3_0101.png["Wallet receive screen with QR code displayed.  Image derived from Bitcoin Design Guide CC-BY"]
 
 The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera.
@@ -429,7 +427,7 @@ many users choose to maintain dedicated exchange accounts independent from
 their ((("bitcoins", "currency exchanges", startref="bitcoin-exchange")))((("currency exchanges", startref="currency-exchange")))wallets.
 ====
 
-Alice was introduced to Bitcoin by a friend so she has an easy way to acquire her first bitcoins. Next, we will look at how she buys bitcoins from her friend Joe and how Joe sends the bitcoins to her ((("bitcoins", "acquiring", startref="bitcoin-acquire")))((("acquiring bitcoins", startref="acquire-bitcoin")))wallet.
+Alice was introduced to Bitcoin by a friend, so she has an easy way to acquire her first bitcoins. Next, we will look at how she buys bitcoins from her friend Joe and how Joe sends the bitcoins to her ((("bitcoins", "acquiring", startref="bitcoin-acquire")))((("acquiring bitcoins", startref="acquire-bitcoin")))wallet.
 
 [[bitcoin_price]]
 ==== Finding the Current Price of Bitcoin
@@ -441,11 +439,11 @@ Bitcoin, like most other currencies, has a _floating exchange rate_. That means
 
 There are hundreds of applications and websites that can provide the current market rate. Here are some of the most popular:
 
-https://bitcoinaverage.com[Bitcoin Average]:: A site that provides a simple view of the volume-weighted-average for each currency.
+https://bitcoinaverage.com[Bitcoin Average]:: A site that provides a simple view of the volume-weighted average for each currency.
 https://coincap.io[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of cryptocurrencies, including bitcoins.
 https://oreil.ly/ACieC[Chicago Mercantile Exchange Bitcoin Reference Rate]:: A reference rate that can be used for institutional and contractual reference, provided as part of investment data feeds by the CME.
 
-In addition to these various sites and applications, some bitcoin
+In addition to these various sites and applications, some Bitcoin
 wallets will automatically convert amounts between bitcoin and other((("bitcoins", "exchange rate", startref="bitcoin-exchange-rate")))((("exchange rate", startref="exchange-rate")))((("current price of bitcoins", startref="current-price")))
 currencies.
 
@@ -484,7 +482,7 @@ amount, because he is about to transmit money and mistakes will soon become
 irreversible. After double-checking the address and amount, he presses
 Send to transmit the transaction. Joe's mobile Bitcoin wallet constructs
 a transaction that assigns 0.001 BTC to the address provided by Alice,
-sourcing the funds from Joe's wallet and signing the transaction with
+sourcing the funds from Joe's wallet, and signing the transaction with
 Joe's private keys. This tells the Bitcoin network that Joe has
 authorized a transfer of value to Alice's new address. As the
 transaction is transmitted via the peer-to-peer protocol, it quickly

ch02_overview.adoc

@@ -26,7 +26,7 @@ interactions between several users by sending
 funds from one wallet to another. While tracking a transaction through
 the Bitcoin network to the blockchain, we will use a _blockchain
 explorer_ site to visualize each step. A blockchain explorer is a web
-application that operates as a bitcoin search engine, in that it allows
+application that operates as a Bitcoin search engine, in that it allows
 you to search for addresses, transactions, and blocks and see the
 relationships and flows between them.
 
@@ -67,7 +67,7 @@ Alice, ((("transactions", "spending bitcoins", id="transaction-spend")))((("bitc
 acquired her first bitcoins. In <<getting_first_bitcoin>>, Alice met with
 her friend Joe to exchange some cash for bitcoins. Since then, Alice has
 bought additional bitcoins.  Now Alice will make
-her first spending transaction, buying access to a premium podcast episode from Bob's online store.
+her first spending transaction: buying access to a premium podcast episode from Bob's online store.
 
 Bob's web store recently started accepting bitcoin payments by adding a
 Bitcoin option to its website. The prices at Bob's store are listed in
@@ -75,7 +75,7 @@ the local currency (US dollars), but at checkout, customers have the
 option of paying in either dollars or bitcoin.
 
 Alice finds the podcast episode she wants to buy and proceeds to the checkout page. At checkout,
-Alice is offered the option to pay with bitcoin, in addition to the
+Alice is offered the option to pay with bitcoin in addition to the
 usual options. The checkout cart displays the price in US dollars and
 also in bitcoin (BTC), at Bitcoin's prevailing exchange rate.
 
@@ -139,16 +139,7 @@ rules also apply to other bitcoin bookkeeping units, such as
 millibitcoins and satoshis.
 ====
 
-You can examine Alice's transaction to Bob's Store on the blockchain
-using((("transactions", "spending bitcoins", startref="transaction-spend")))((("bitcoins", "spending", startref="bitcoin-spend")))((("spending bitcoins", startref="spend-bitcoin"))) a block explorer site (<<view_alice_transaction>>).
-
-[[view_alice_transaction]]
-.View Alice's transaction on https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef[Blockstream Explorer]
-====
-----
-https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef
-----
-====
+You can use a block explorer to examine blockchain data, such as the payment made to Bob in Alice's((("transactions", "spending bitcoins", startref="transaction-spend")))((("bitcoins", "spending", startref="bitcoin-spend")))((("spending bitcoins", startref="spend-bitcoin"))) https://oreil.ly/hAeyh[transaction].
 
 In the following sections, we will examine this transaction in more
 detail. We'll see how Alice's wallet constructed it, how it was
@@ -264,7 +255,7 @@ change output (and the address it pays, called a _change address_) and a
 payment output.
 
 Importantly, the change address does not have to be the
-same address as that of the input and for privacy reasons is often a new
+same address as that of the input and, for privacy reasons, is often a new
 address from the owner's wallet.  In ideal circumstances, the two
 different uses of outputs both use never-before-seen addresses and
 otherwise look identical, preventing any third party from determining
@@ -273,17 +264,17 @@ illustration purposes, we've added shading to the change outputs in
 <<transaction-chain>>.
 
 Not every transaction has a change output.  Those that don't are ((("changeless transactions")))((("transactions", "changeless")))called
-_changeless transactions_ and they can have only a single output.
+_changeless transactions_, and they can have only a single output.
 Changeless transactions are only a practical option if the amount being
 spent is roughly the same as the amount available in the transaction
-inputs minus the anticipated transaction fee.  In <<transaction-chain>>
+inputs minus the anticipated transaction fee.  In <<transaction-chain>>,
 we see Bob creating Tx3 as a changeless transaction that spends the
 output he ((("transactions", "change output", startref="transaction-change-output")))((("change output", startref="change-output")))((("outputs", "change output", startref="output-change")))received in Tx2.
 
 ==== Coin Selection
 
 Different wallets((("transactions", "coin selection")))((("coin selection in transactions")))((("selecting", "coins in transactions"))) use different strategies when choosing which
-inputs to se in a payment, called _coin selection_.
+inputs to use in a payment, called _coin selection_.
 
 They might aggregate many small
 inputs, or use one that is equal to or larger than the desired payment.
@@ -348,9 +339,9 @@ wants to send to Bob. Most wallets keep track of all the available
 outputs belonging to addresses in the wallet. Therefore, Alice's wallet
 would contain a copy of the transaction output from Joe's transaction,
 which was created in exchange for cash (see <<getting_first_bitcoin>>).
-A bitcoin wallet application that runs on a full node actually
+A Bitcoin wallet application that runs on a full node actually
 contains a copy of every confirmed transaction's ((("UTXOs (unspent transaction outputs)")))unspent outputs, called
-_Unspent Transaction Outputs_ (UTXOs).
+_unspent transaction outputs_ (UTXOs).
 However, because full nodes use more resources, many
 user wallets run lightweight clients that track only the user's own
 UTXOs.
@@ -358,7 +349,7 @@ UTXOs.
 In this case, this single
 UTXO is sufficient to pay for the podcast. Had this not been the case,
 Alice's wallet application might have to combine several
-smaller UTXOs, like picking coins from a purse until it could
+smaller UTXOs, like picking coins from a purse, until it could
 find enough to pay for the podcast. In both cases, there might be a need
 to get some change back, which we will see in the next section, as the
 wallet application creates the transaction outputs (payments).
@@ -375,7 +366,7 @@ address, only Bob's wallet can present such a signature to later spend this
 output. Alice will therefore _encumber_ the output value with a demand
 for a signature from Bob.
 
-This transaction will also include a second output, ((("change output")))because Alice's
+This transaction will also include a second output ((("change output")))because Alice's
 funds contain more money than the cost of the
 podcast. Alice's change
 output is created in the very same
@@ -386,7 +377,7 @@ then spend the change output in a subsequent transaction.
 Finally, for the transaction to be processed by the network in a((("transaction fees"))) timely
 fashion, Alice's wallet application will add a small fee. The fee is not
 explicitly stated in the transaction; it is implied by the difference in value between
-inputs and outputs.  This _transaction fee_ is collected by the
+inputs and outputs.  This transaction fee is collected by the
 miner as a fee for including the transaction in a block
 that gets recorded on the blockchain.
 
@@ -501,7 +492,7 @@ Bitcoin users will accept the block with its transactions as a
 valid block.  If the output doesn't match the template, the miner makes
 a small change to their candidate block and tries again.  As of this
 writing, the number of candidate blocks miners need to try before finding
-a winning combination is about 168 billion trillions.  That's also how
+a winning combination is about 168 billion trillion.  That's also how
 many times the hash function needs to be run.
 
 However, once a winning combination has been found, anyone can verify
@@ -628,8 +619,8 @@ look like <<block-alice2>>.
 image::images/mbc3_0209.png["Alice's transaction as part of a transaction chain"]
 
 In this chapter, we((("transactions", "spending bitcoins", startref="transaction-spend2")))((("bitcoins", "spending", startref="bitcoin-spend2")))((("spending bitcoins", startref="spend-bitcoin2"))) saw how transactions build a chain that moves value
-from owner to owner. We also tracked Alice's transaction, from the
-moment it was created in her wallet, through the Bitcoin network and to
+from owner to owner. We also tracked Alice's transaction from the
+moment it was created in her wallet, through the Bitcoin network, and to
 the miners who recorded it on the blockchain. In the rest of this book,
 we will examine the specific technologies behind wallets, addresses,
 signatures, transactions, the network, and finally, mining.

ch03_bitcoin-core.adoc

@@ -36,8 +36,8 @@ full time and several dozen more on a part-time basis. Anyone can
 contribute to the code—including you!
 
 When Bitcoin was created by Satoshi Nakamoto, the
-software was mostly completed before publication of the whitepaper reproduced in
-<<satoshi_whitepaper>>. Satoshi wanted to make sure the
+software was mostly completed before publication of the whitepaper (reproduced in
+<<satoshi_whitepaper>>). Satoshi wanted to make sure the
 implementation worked before publishing a paper about it. That first implementation, then simply
 known as "Bitcoin," has been heavily modified and
 improved. It has evolved into what is known as _Bitcoin Core_, to
@@ -83,17 +83,17 @@ source repository from GitHub.  On the https://oreil.ly/hN9g1[Bitcoin Core downl
 page], select the most recent version and download the compressed
 archive of the source code. Alternatively, use the Git command line to create a
 local copy of the source code from the
-https://oreil.ly/BdOwl[GitHub bitcoin page].
+https://oreil.ly/BdOwl[GitHub Bitcoin page].
 
 [TIP]
 ====
 In
-many of the ((("command prompts")))((("shell command prompts")))examples in this chapter we will be using the operating
+many of the ((("command prompts")))((("shell command prompts")))examples in this chapter, we will be using the operating
 system's command-line interface (also known as a "shell"), accessed via
 a "terminal" application. The shell will display a prompt, you type a
 command, and the shell responds with some text and a new prompt for your
 next command. The prompt may look different on your system, but in the
-following examples it is denoted by a +$+ symbol. In the examples, when
+following examples, it is denoted by a +$+ symbol. In the examples, when
 you see text after a +$+ symbol, don't type the +$+ symbol but type the
 command immediately following it, then press Enter to execute the
 command. In the examples, the lines below each command are the operating
@@ -318,7 +318,7 @@ cores if they are available. If all goes well, Bitcoin Core is now
 compiled. You should run the unit test suite with +make check+ to ensure
 the linked libraries are not broken in obvious ways. The final step is
 to install the various executables on your system using the +make
-install+ command. You may be prompted for your user password, because
+install+ command. You may be prompted for your user password because
 this step requires administrative privileges:
 
 ----
@@ -487,10 +487,10 @@ inside the configuration file it refers to.
 ++datadir++:: Select((("datadir option (bitcoind command)"))) the directory and filesystem in which to put all the
 blockchain data. By default this is the _.bitcoin_ subdirectory of your
 home directory. Depending on your configuration, this can use from about 10
-gigabytes to almost 1 terabyte as of this writing, with the maximum size
+GB to almost 1 TB as of this writing, with the maximum size
 expected to increase by several hundred gigabytes per year.
 
-++prune++:: Reduce the((("prune option (bitcoind command)"))) blockchain disk space requirements to this many megabytes, by
+++prune++:: Reduce the((("prune option (bitcoind command)"))) blockchain disk space requirements to this many megabytes by
 deleting old blocks. Use this on a resource-constrained node that can't
 fit the full blockchain.  Other parts of the system will use other disk
 space that can't currently be pruned, so you will still need at least
@@ -500,7 +500,7 @@ the minimum amount of space mentioned in the +datadir+ option.
 programmatically retrieve any transaction by its ID provided that the
 block containing that transaction hasn't been pruned.
 
-++dbcache++:: The size((("dbcache option (bitcoind command)"))) of the UTXO cache. The default is 450 MiB. Increase
+++dbcache++:: The size((("dbcache option (bitcoind command)"))) of the UTXO cache. The default is 450 mebibytes (MiB). Increase
 this size on high-end hardware to read and write from your disk less
 often, or reduce the size on low-end hardware to save memory at the
 expense of using your disk more frequently.
@@ -527,7 +527,7 @@ indexing, you need to
 wait for it to rebuild the index.
 ****
 
-<<full_index_node>> shows how you might combine the preceding options,
+<<full_index_node>> shows how you might combine the preceding options
 with a fully indexed node, running as an API backend for a bitcoin
 application.
 
@@ -582,7 +582,7 @@ $ bitcoind -printtoconsole
 2023-01-28T03:43:39Z scheduler thread start
 2023-01-28T03:43:39Z [http] creating work queue of depth 16
 2023-01-28T03:43:39Z Using random cookie authentication.
-2023-01-28T03:43:39Z Generated RPC authentication cookie /lotsofspace/bitcoin/.cookie
+2023-01-28T03:43:39Z Generated RPC cookie /lotsofspace/bitcoin/.cookie
 2023-01-28T03:43:39Z [http] starting 4 worker threads
 2023-01-28T03:43:39Z Using wallet directory /lotsofspace/bitcoin/wallets
 2023-01-28T03:43:39Z init message: Verifying wallet(s)…
@@ -681,8 +681,8 @@ Result:
 Examples:
 > bitcoin-cli getblockhash 1000
 > curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest",
-"method": "getblockhash", 
-"params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
+  "method": "getblockhash", 
+  "params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
 ----
 
 At the end of the help information you will see two examples of the RPC
@@ -774,7 +774,7 @@ on how many blocks your ((("Bitcoin Core", "command-line interface", "status inf
 In <<spending_bitcoin>>, Alice ((("Bitcoin Core", "command-line interface", "exploring/decoding transactions", id="bitcoin-core-command-transaction")))((("command-line interface (Bitcoin Core)", "exploring/decoding transactions", id="command-transaction")))((("transactions", "exploring/decoding", id="transactions-explore-decode")))((("exploring", "transactions", id="explore-transaction")))((("decoding", "transactions", id="decode-transaction")))made a purchase from Bob's store. Her
 transaction was recorded on the blockchain.
 Let's use the API to retrieve and examine that transaction by passing
-the txid as a parameter:
+the transaction ID (txid) as a parameter:
 
 [[alice_tx_serialized]]
 .Alice's serialized transaction
@@ -882,7 +882,7 @@ Bob and the change back to Alice.
 We can further explore the blockchain by examining the previous
 transaction referenced by its +txid+ in this transaction using the same
 commands (e.g., +getrawtransaction+). Jumping from transaction to
-transaction we can follow a chain of transactions back as the coins are
+transaction, we can follow a chain of transactions back as the coins are
 transmitted from one owner to the((("Bitcoin Core", "command-line interface", "exploring/decoding transactions", startref="bitcoin-core-command-transaction")))((("command-line interface (Bitcoin Core)", "exploring/decoding transactions", startref="command-transaction")))((("transactions", "exploring/decoding", startref="transactions-explore-decode")))((("exploring", "transactions", startref="explore-transaction")))((("decoding", "transactions", startref="decode-transaction"))) next.
 
 ==== Exploring Blocks
@@ -928,7 +928,7 @@ f6cd83c3ca
   "difficulty": 157416.4018436489,
   "chainwork": "[...]00000000000000000000000000000000000000541788211ac227bc",
   "nTx": 13,
-  "previousblockhash": "[...]000b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
+  "previousblockhash": "[...]0b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
   "nextblockhash": "[...]00129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66",
   "strippedsize": 4179,
   "size": 4179,
@@ -968,8 +968,7 @@ we'll examine those ((("Bitcoin Core", "command-line interface", "exploring bloc
 
 The
 +bitcoin-cli+ helper is ((("Bitcoin Core", "command-line interface", "API access", id="bitcoin-core-command-api")))((("command-line interface (Bitcoin Core)", "API access", id="command-api")))((("API access", id="api")))very useful for exploring the Bitcoin Core API
-and testing functions. But the whole point of an application programming
-interface is to access functions programmatically. In this section we
+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
@@ -985,8 +984,8 @@ client to construct one of these JSON-RPC calls:
 
 ----
 $ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest",
-"method": "getblockchaininfo", 
-"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
+  "method": "getblockchaininfo", 
+  "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
 ----
 
 This command shows that +curl+ submits an HTTP request to the local host
@@ -1006,13 +1005,13 @@ any higher-level Bitcoin Core RPC wrappers), ((("Bitcoin Core", "authentication"
 ====
 ----
 $ cat .bitcoin/.cookie
-__cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
+  __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
 
 $ curl 
---user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0 
---data-binary '{"jsonrpc": "1.0", "id":"curltest", 
-"method": "getblockchaininfo", 
-"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
+  --user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0 
+  --data-binary '{"jsonrpc": "1.0", "id":"curltest", 
+  "method": "getblockchaininfo", 
+  "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
 
 {"result":{"chain":"main","blocks":799278,"headers":799278,
 "bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879",
@@ -1150,7 +1149,7 @@ https://oreil.ly/xn_rg[python-bitcoinlib]::  A ((("Python toolkits")))((("python
 https://oreil.ly/wcpXP[pycoin]:: A Python bitcoin library by Richard Kiss
 
 ==== Go
-https://oreil.ly/h5MEI[btcd]:: A ((("Go toolkits")))((("btcd")))Go language full-node Bitcoin client
+https://oreil.ly/h5MEI[btcd]:: A ((("Go toolkits")))((("btcd")))Go language, full-node Bitcoin client
 
 ==== Rust
 https://oreil.ly/me6gf[rust-bitcoin]:: Rust ((("Rust toolkits")))((("rust-bitcoin")))bitcoin library for serialization, parsing, and API calls
@@ -1161,7 +1160,7 @@ https://bitcoin-s.org[bitcoin-s]:: A ((("Scala toolkits")))((("bitcoin-s")))Bitc
 ==== C#
 https://oreil.ly/Qfjgq[NBitcoin]:: Comprehensive((("C# toolkits")))((("NBitcoin"))) bitcoin library for the .NET framework
 
-Many more libraries exist in a variety of other programming languages
+Many more libraries exist in a variety of other programming languages,
 and more are created all the time.
 
 If you followed the instructions in this chapter, you now have Bitcoin

ch04_keys.adoc

@@ -13,7 +13,7 @@ The original Bitcoin paper describes a very simple scheme for achieving
 those goals, shown in <<pay-to-pure-pubkey>>.  A receiver like Bob
 accepts bitcoins to a public key in a transaction that is signed by the
 spender (like Alice).  The bitcoins that Alice is spending had been
-previously received to one her public keys, and she uses the
+previously received to one of her public keys, and she uses the
 corresponding private key to generate her signature.  Full nodes can
 verify that Alice's signature commits to the output of a hash function
 that itself commits to Bob's public key and other transaction details.
@@ -93,10 +93,10 @@ over the private key is the root of user control over all funds
 associated with the corresponding Bitcoin public key. The private key is
 used to create signatures that are used to spend bitcoins by proving
 control of funds used in a transaction. The private key must remain
-secret at all times, because revealing it to third parties is equivalent
+secret at all times because revealing it to third parties is equivalent
 to giving them control over the bitcoins secured by that key. The private
-key must also be backed up and protected from accidental loss, because
-if it's lost it cannot be recovered and the funds secured by it are
+key must also be backed up and protected from accidental loss because
+if it's lost, it cannot be recovered and the funds secured by it are
 forever lost too.
 
 [TIP]
@@ -119,7 +119,7 @@ number generators to produce 256 bits of entropy.
 
 More precisely, the private key can be any number between +0+ and +n -
 1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less
-than 2^256^) defined as the order of the elliptic curve used in bitcoin
+than 2^256^) defined as the order of the elliptic curve used in Bitcoin
 (see <<elliptic_curve>>). To create such a key, we randomly pick a
 256-bit number and check that it is less than +n+. In programming terms,
 this is usually achieved by feeding a larger string of random bits,
@@ -150,7 +150,7 @@ bits):
 
 [TIP]
 ====
-The size of Bitcoin's private key space, (2^256^) is an unfathomably
+The size of Bitcoin's private key space (2^256^) is an unfathomably
 large number. It is approximately 10^77^ in decimal. For comparison, the
 visible universe is estimated to((("private keys", "generating", startref="private-key-generate"))) contain 10^80^ atoms.
 ====
@@ -268,7 +268,7 @@ interest to points on the curve with two integer coordinates!
 
 In some cases (i.e., if P~1~ and P~2~ have the same x values but
 different y values), the tangent line will be exactly vertical, in which
-case P3 = "point at infinity."
+case P~3~ = "point at infinity."
 
 If P~1~ is the "point at infinity," then P~1~ + P~2~ = P~2~. Similarly,
 if P~2~ is the point at infinity, then P~1~ + P~2~ = P~1~. This shows
@@ -292,7 +292,7 @@ irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a
 constant point called the _generator point_, and _K_ is the resulting
 public key. The reverse operation, known as "finding the discrete
 logarithm"—calculating _k_ if you know __K__—is as difficult as trying
-all possible values of _k_, i.e., a brute-force search. Before we
+all possible values of _k_ (i.e., a brute-force search). Before we
 demonstrate how to generate a public key from a private key, let's look
 at elliptic curve cryptography in a bit more detail.
 
@@ -325,9 +325,9 @@ bitcoin:
 
 where _k_ is the private key, _G_ is the generator point, and _K_ is the
 resulting public key, a point on the curve. Because the generator point
-is always the same for all bitcoin users, a private key _k_ multiplied
+is always the same for all Bitcoin users, a private key _k_ multiplied
 with _G_ will always result in the same public key _K_. The relationship
-between _k_ and _K_ is fixed, but can only be calculated in one
+between _k_ and _K_ is fixed but can only be calculated in one
 direction, from _k_ to _K_. That's why a Bitcoin public key can be
 shared with anyone and does not reveal the user's private key (_k_).
 
@@ -339,7 +339,7 @@ one way.
 ====
 
 Implementing the elliptic curve multiplication, we take the private key
-_k_ generated previously and multiply it with the generator point G to
+_k_ generated previously and multiply it with the generator point _G_ to
 find the public key _K_:
 
 [source, python]
@@ -533,11 +533,11 @@ was the exact same key that was used to create that earlier commitment.
 The SHA256 hash function is considered to be very secure and produces
 256 bits (32 bytes) of output, less than half the size of original
 Bitcoin public keys.  However, there are other slightly less secure hash
-functions that produce smaller output, such as the ((("RIPEMD160 hash function")))RIPEMD160 hash
+functions that produce smaller output, such as the ((("RIPEMD-160 hash function")))RIPEMD-160 hash
 function whose output is 160 bits (20 bytes).  For reasons Satoshi
 Nakamoto never stated, the original version of Bitcoin made commitments
 to public keys by first hashing the key with SHA256 and then hashing
-that output with RIPEMD160; this produced a 20-byte commitment to the
+that output with RIPEMD-160; this produced a 20-byte commitment to the
 public key.
 
 We can look at that algorithmically.
@@ -754,15 +754,14 @@ When ((("public key cryptography", "compressed public keys", id="pub-key-compres
 alternative encoding for public keys that used only 33 bytes and which
 was backward compatible with all Bitcoin full nodes at the time,
 so there was no need to change the Bitcoin protocol.  Those 33-byte
-public keys are known as _compressed public keys_ and the original 65
-byte keys are known as _uncompressed public keys_.  Using smaller public keys
+public keys are known as _compressed public keys_, and the original 65-byte keys are known as _uncompressed public keys_.  Using smaller public keys
 results in smaller transactions, allowing more payments to be made in the same
 block.
 
 As we saw in the section <<public_key_derivation>>, a public key is a point (x,y) on an
 elliptic curve. Because the curve expresses a mathematical function, a
 point on the curve represents a solution to the equation and, therefore,
-if we know the _x_ coordinate we can calculate the _y_ coordinate by
+if we know the _x_ coordinate, we can calculate the _y_ coordinate by
 solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to
 store only the _x_ coordinate of the public key point, omitting the _y_
 coordinate and reducing the size of the key and the space required to
@@ -796,8 +795,8 @@ positive or negative value. Visually, this means that the resulting _y_
 coordinate can be above or below the x-axis. As you can see from the
 graph of the elliptic curve in <<ecc-curve>>, the curve is symmetric,
 meaning it is reflected like a mirror by the x-axis. So, while we can
-omit the _y_ coordinate we have to store the _sign_ of _y_ (positive or
-negative); or in other words, we have to remember if it was above or
+omit the _y_ coordinate, we have to store the _sign_ of _y_ (positive or
+negative); in other words, we have to remember if it was above or
 below the x-axis because each of those options represents a different
 point and a different public key. When calculating the elliptic curve in
 binary arithmetic on the finite field of prime order p, the _y_
@@ -821,9 +820,9 @@ This compressed public key corresponds to the same private key, meaning
 it is generated from the same private key. However, it looks different
 from the uncompressed public key. More importantly, if we convert this
 compressed public key to a commitment using the HASH160
-function (+RIPEMD160(SHA256(K))+) it will produce a _different_
+function (+RIPEMD160(SHA256(K))+), it will produce a _different_
 commitment than the uncompressed public key, leading to a different
-address. This can be confusing, because it means that a single private
+address. This can be confusing because it means that a single private
 key can produce a public key expressed in two different formats
 (compressed and uncompressed) that produce two different Bitcoin
 addresses. However, the private key is identical for both Bitcoin
@@ -835,7 +834,7 @@ addresses.
 image::images/mbc3_0408.png["pubkey_compression"]
 
 Compressed public keys are now the default in almost all Bitcoin
-software, and were made required when using certain new features added
+software and were required when using certain new features added
 in later protocol upgrades.
 
 However, some software still needs to support uncompressed public keys,
@@ -847,7 +846,7 @@ to scan for the correct type can lead to the user not being able to
 spend their full balance.  To resolve this issue, when private keys are
 exported from a wallet, the WIF that is used to
 represent them is implemented slightly differently in newer Bitcoin
-wallets, to indicate that these private keys have been used to produce((("public key cryptography", "compressed public keys", startref="pub-key-compress")))((("compressed public keys", startref="compress-pub-key")))((("uncompressed public keys", startref="uncompress-pub-key")))
+wallets to indicate that these private keys have been used to produce((("public key cryptography", "compressed public keys", startref="pub-key-compress")))((("compressed public keys", startref="compress-pub-key")))((("uncompressed public keys", startref="uncompress-pub-key")))
 compressed public keys.
 
 [[addresses_for_p2sh]]
@@ -962,7 +961,7 @@ the HASH160 algorithm.  This is((("second preimage attacks"))) a _second preimag
 
 However, this changes when an attacker is able to influence the original input
 value. For example, an attacker participates in the creation of a
-multisignature script where tthey don't need to submit their public key until after they learn all of the other partys' public keys.
+multisignature script where they don't need to submit their public key until after they learn all of the other partys' public keys.
 In that case, the strength of hash algorithm is reduced to its square
 root.  For HASH160, the probability becomes 1-in-2^80^.  This is a
 _collision attack_.
@@ -985,9 +984,9 @@ processes involving multiple parties, which could make the attack
 profitable.
 
 There are well-established cryptographic protocols for preventing
-collision attacks but a simple solution that doesn't require any
+collision attacks, but a simple solution that doesn't require any
 special knowledge on the part of wallet developers is to simply use
-a stronger hash function.  Later upgrades to Bitcoin made that possible
+a stronger hash function.  Later upgrades to Bitcoin made that possible,
 and newer Bitcoin addresses provide at least 128 bits of collision
 resistance.  To perform 2^128^ hash operations would take all current
 Bitcoin miners about 32 billion years.
@@ -1028,7 +1027,7 @@ identified several problems((("public key cryptography", "base58check encoding")
 - Its mixed-case presentation made it inconvenient to read aloud or
   transcribe.  Try reading one of the legacy addresses in this chapter
   to a friend who you have transcribe it.  Notice how you have to prefix
-  every letter with the words "uppercase" and "lowercase."  Also note
+  every letter with the words "uppercase" and "lowercase."  Also, note
   when you review their writing that the uppercase and lowercase
   versions of some letters can look similar in many people's
   handwriting.
@@ -1173,20 +1172,20 @@ time in a billion.
 //https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb
 
 The version of bech32 with a single different constant is known as
-Bech32 Modified (bech32m).  All of the characters in bech32 and bech32m
+bech32 modified (bech32m).  All of the characters in bech32 and bech32m
 addresses for the same underlying data will be identical except for the
 last six (the checksum).  That means a wallet will need to know which
 version is in use in order to validate the checksum, but both address
 types contain an internal version byte that makes determining that easy.
 
-===== Encoding and Decoding bech32m addresses
 
-In this((("encoding", "bech32m addresses", id="encode-bech32m")))((("decoding", "bech32m addresses", id="decode-bech32m"))) section, we'll look at the encoding and parsing rules for
+
+To work with both bech32 and((("encoding", "bech32m addresses", id="encode-bech32m")))((("decoding", "bech32m addresses", id="decode-bech32m"))) bech32m, we'll look at the encoding and parsing rules for
 bech32m Bitcoin addresses since they encompass the ability to parse
 bech32 addresses and are the current recommended address format for
 Bitcoin wallets.
 
-Bech32m addresses start with a Human Readable Part (HRP).  There are
+Bech32m addresses start with a human readable part (HRP).  There are
 rules in BIP173 for creating your own HRPs, but for Bitcoin you only
 need to know about the HRPs already chosen, shown in
 <<bech32_hrps_for_bitcoin>>.
@@ -1284,19 +1283,19 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
 <tbody>
 <tr>
 <td><p>P2WPKH</p></td>
-<td><p>OP_0 2b626ed108ad00a944bb2922a309844611d25468</p></td>
+<td><p><code>OP_0 2b626ed108ad00a944bb2922a309844611d25468</code></p></td>
 </tr>
 <tr>
 <td><p>P2WSH</p></td>
-<td><p>OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f</p></td>
+<td><p><code>OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f</code></p></td>
 </tr>
 <tr>
 <td><p>P2TR</p></td>
-<td><p>OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311</p></td>
+<td><p><code>OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311</code></p></td>
 </tr>
 <tr>
 <td><p>Future Example</p></td>
-<td><p>OP_16 0000</p></td>
+<td><p><code>OP_16 0000</code></p></td>
 </tr>
 </tbody>
 </table>
@@ -1314,7 +1313,7 @@ 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
 some cases; for details, see <<p2sh_collision_attacks>>.  A result of
-using SHA256 without RIPEMD160 is that P2WSH commitments are 32 bytes
+using SHA256 without RIPEMD-160 is that P2WSH commitments are 32 bytes
 (256 bits) instead 20 bytes (160 bits).
 
 For the pay-to-taproot (P2TR) output, the witness program is a point on
@@ -1328,12 +1327,12 @@ program (2 bytes) with a null value.
 
 Now that we know the version number and the witness program, we can
 convert each of them into a bech32 address.  Let's use the bech32m reference
-library for Python to quickly generate those addresses, and then take a
+library for Python to quickly generate those addresses and then take a
 deeper look at what's happening:
 
 ----
 $ github="https://raw.githubusercontent.com"
-$ wget $github//sipa/bech32/master/ref/python/segwit_addr.py
+$ wget $github/sipa/bech32/master/ref/python/segwit_addr.py
 
 $ python
 >>> from segwit_addr import *
@@ -1385,7 +1384,8 @@ decode(hrp, addr)
 >>> _ = decode("bc", "bc1q9d3xa5gg45q2j39m9y32xzvygcgay4rgc6aaee")
 >>>  _[0], bytes(_[1]).hex()
 (0, '2b626ed108ad00a944bb2922a309844611d25468')
->>> _ = decode("bc", "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
+>>> _ = decode("bc",
+        "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
 >>> _[0], bytes(_[1]).hex()
 (1, '2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311')
 ----
@@ -1523,7 +1523,7 @@ can easily be converted to any other((("private keys", "formats", startref="priv
 ==== Compressed Private Keys
 
 The commonly((("private keys", "compressed", id="private-key-compress")))((("compressed private keys", id="compress-private-key"))) used term "compressed private key" is a misnomer, because when a private
-key is exported as WIF-compressed it is actually one byte _longer_ than
+key is exported as WIF-compressed, it is actually one byte _longer_ than
 an "uncompressed" private key. That is because the private key has an
 added one-byte suffix (shown as 01 in hex in <<table_4-4>>), which
 signifies that the private key is from a newer wallet and should only be
@@ -1596,8 +1596,8 @@ addresses and those will be used in transactions. When exporting private
 keys from a new wallet that implements compressed public keys, the WIF
 is modified, with the addition of a one-byte suffix +01+ to the private
 key. The resulting base58check-encoded private key is called a
-"compressed WIF" and starts with the letter _K_ or _L_, instead of
-starting with "5" as is the case with WIF-encoded (uncompressed) keys
+"compressed WIF" and starts with the letter _K_ or _L_ instead of
+starting with "5," as is the case with WIF-encoded (uncompressed) keys
 from((("private keys", "compressed", startref="private-key-compress")))((("compressed private keys", startref="compress-private-key"))) older wallets.
 
 === Advanced Keys and Addresses
@@ -1613,7 +1613,7 @@ addresses that contain human-readable messages. For example,
 +1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains
 the letters forming the word "Love" as the first four base58 letters.
 Vanity addresses require generating and testing billions of candidate
-private keys, until a Bitcoin address with the desired pattern is found.
+private keys until a Bitcoin address with the desired pattern is found.
 Although there are some optimizations in the vanity generation
 algorithm, the process essentially involves picking a private key at
 random, deriving the public key, deriving the Bitcoin address, and
@@ -1767,7 +1767,7 @@ As you can see, Eugenia won't be creating the vanity address
 computers. Each additional character increases the difficulty by a
 factor of 58. Patterns with more than seven characters are usually found
 by specialized hardware, such as custom-built desktops with multiple
-GPUs.
+graphics processing units (GPUs).
 Vanity searches on GPU systems are many orders of magnitude
 faster than on a general-purpose CPU.
 
@@ -1842,7 +1842,7 @@ image::images/mbc3_0410.png[]
 Some are intended to be given as gifts and have seasonal themes, such as
 Christmas and New Year's. Others are designed for storage in a
 bank vault or safe with the private key hidden in some way, either with
-opaque scratch-off stickers, or folded and sealed with tamper-proof
+opaque scratch-off stickers or folded and sealed with tamper-proof
 adhesive foil.  Other designs feature additional copies of the key and
 address, in the form of detachable stubs similar to ticket stubs,
 allowing you to store multiple copies to protect against fire, flood, or

ch05_wallets.adoc

@@ -72,7 +72,7 @@ be able to predict the new output--not even if they know the new input.
 
 This allows us to take one random value and transform it into a
 practically unlimited number of seemingly random values.  Even more
-usefully, later using the same hash function with the same ((("seeds")))input
+useful, later using the same hash function with the same ((("seeds")))input
 (called a _seed_) will produce the same seemingly random values:
 
 ----
@@ -160,7 +160,7 @@ that corresponds to the public child key Bob created.
 In other words, it's possible to create child public keys even if you
 don't know anything about the parent private key.  The value added to a
 public key is ((("key tweaks")))known as a _key tweak._  If a deterministic algorithm is
-used for generating the key tweaks, then it's possible to for someone
+used for generating the key tweaks, then it's possible for someone
 who doesn't know the private key to create an essentially unlimited
 sequence of public child keys from a single public parent key. The
 person who controls the private parent key can then use the same key
@@ -179,7 +179,7 @@ transactions to the less-secure frontend for broadcast to the Bitcoin
 network.
 
 Public child key derivation can produce a linear sequence of keys
-similar to the previously seen <<Type1_wallet>>, but modern wallets
+similar to the previously seen <<Type1_wallet>>, but modern wallet
 applications use one more trick to provide a tree of keys instead a
 single sequence, as described in the((("wallets", "key generation", "public child key derivation", startref="wallet-keygen-public-child")))((("key generation", "public child key derivation", startref="keygen-public-child")))((("public child key derivation", startref="public-child-derive")))((("child key pair derivation", startref="child-key-pair"))) following section.
 
@@ -278,7 +278,7 @@ BIP39::
   adding a checksum to it, and encoding the data into a series of 12 to
   24 words (which may be localized to a user's native language).  The
   words (plus an optional passphrase) are run through a _key-stretching
-  function_ and the output is used as a seed.  BIP39 recovery codes have
+  function_, and the output is used as a seed.  BIP39 recovery codes have
   several shortcomings, which later schemes attempt to address.
 
 Electrum v2::
@@ -299,7 +299,7 @@ Aezeed::
   cryptographic properties of the recovery code.  
   It also includes a _wallet birthday_
   in the recovery code, a reference to the date when the user created
-  the wallet database; this allows a restoration process to find all of
+  the wallet database. This allows a restoration process to find all of
   the funds associated with a wallet without scanning the entire
   blockchain, which is especially useful for privacy-focused lightweight clients.
   It includes support for changing the passphrase or changing other
@@ -318,7 +318,7 @@ Muun::
   Although this is unwieldy compared to the BIP39, Electrum v2, and
   Aezeed recovery codes, it provides support for new technologies and
   standards that are becoming more common in new wallets, such as
-  Lightning Network support, output script descriptors, and miniscript.
+  Lightning Network (LN) support, output script descriptors, and miniscript.
 
 SLIP39::
   A successor ((("SLIP39 recovery codes")))to BIP39 with some of the same authors, SLIP39 allows
@@ -467,12 +467,12 @@ amount of every transaction listed but a blank entry for the
 Wallets should provide their users with a convenient way to back up
 label data.  That seems obvious, but there are a number of
 widely used wallet applications that make it easy to create and use
-recovery codes but which provide no way to back up or restore label
+recovery codes but that provide no way to back up or restore label
 data.
 
 Additionally, it may be useful for wallet applications to provide a
 standardized format to export labels so that they can be used in other
-applications, e.g., accounting software.  A standard for that ((("labels, backing up", startref="label-backup")))format is
+applications (e.g., accounting software).  A standard for that ((("labels, backing up", startref="label-backup")))format is
 proposed in BIP329.
 
 Wallet applications implementing additional protocols beyond basic
@@ -507,7 +507,7 @@ and additional ((("wallets", "nonkey data, backing up", startref="wallet-nonkey-
 ==== Backing Up Key Derivation Paths
 
 In a ((("wallets", "key generation", "backing up derivation paths", id="wallet-keygen-backups")))((("key generation", "backing up derivation paths", id="keygen-backups")))((("backing up", "key derivation paths", id="backup-key-derive")))BIP32 tree of keys, there are approximately four billion first-level
-keys and each of those keys can have its own four billion children, with
+keys; each of those keys can have its own four billion children, with
 those children each potentially having four billion children of their
 own, and so on.  It's not possible for a wallet application to generate
 even a small fraction of every possible key in a BIP32 tree, which means
@@ -611,7 +611,7 @@ included directly.  Their disadvantage is that they require users to back
 up additional information along with their recovery code.  The
 additional information usually can't compromise a user's security, so it
 doesn't require as much protection as the recovery code, although it can
-reduce their privacy and so does require some protection.
+reduce their privacy and does require some protection.
 
 Almost all wallet applications that use explicit paths as of this
 writing use the _output script descriptors_ standard (called
@@ -660,14 +660,14 @@ Developers of modern wallets can choose from a variety of different
 technologies to help users create and use backups--and new solutions
 appear every year.  Instead of going into detail about each of the
 options we described earlier in this chapter, we'll focus the rest of
-this chapter on the stack of technologies that we think is most widely
+this chapter on the stack of technologies we think is most widely
 used in wallets as of early 2023:
 
 - BIP39 recovery codes
-- BIP32 hierarchical deterministic (HD) key derivation
+- BIP32 HD key derivation
 - BIP44-style implicit paths
 
-All of these standards have been around since 2014 or earlier and
+All of these standards have been around since 2014 or earlier, and
 you'll have no problem finding additional resources for using them.
 However, if you're feeling bold, we do encourage you to investigate more
 modern standards that may provide additional features or safety.
@@ -678,7 +678,7 @@ modern standards that may provide additional features or safety.
 BIP39 ((("wallets", "recovery codes", id="wallet-recovery-bip39")))((("recovery codes", id="recovery-code-bip39")))((("BIP39 recovery codes", id="bip39-recovery")))recovery codes are word
 sequences that represent (encode) a random number used as a seed to
 derive a deterministic wallet. The sequence of words is sufficient to
-re-create the seed and from there re-create all the
+re-create the seed and from there, re-create all the
 derived keys. A wallet application that implements deterministic wallets
 with a BIP39 recovery code will show the user a sequence of 12 to 24 words when
 first creating a wallet. That sequence of words is the wallet backup and
@@ -693,7 +693,7 @@ Recovery codes((("brainwallets"))) are often confused with
 "brainwallets." They are not the same. The primary difference is that a
 brainwallet consists of words chosen by the user, whereas recovery codes
 are created randomly by the wallet and presented to the user. This
-important difference makes recovery codes much more secure, because
+important difference makes recovery codes much more secure because
 humans are very poor sources of randomness.
 ====
 
@@ -902,7 +902,7 @@ some examples of recovery codes and the seeds ((("key-stretching functions", sta
 </tbody>
 </table>
 <table id="bip39_256_no_pass">
-<caption><span class="label">Table 5-7. </span>256-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption>
+<caption>256-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption>
 <tbody>
 <tr>
 <td><p><strong>Entropy input (256 bits)</strong></p></td>
@@ -966,7 +966,7 @@ greater the entropy, the harder it will be for them to figure out part
 of the code they didn't see.  For example, if an attacker sees half of a
 128-bit code (64 bits), it's plausible that they'll be able to brute
 force the remaining 64 bits.  If they see half of a 256-bit code (128
-bits), it's not plausible that they can brute force the other half.  We
+bits), it's not plausible they can brute force the other half.  We
 don't recommend relying on this defense--either keep your recovery codes
 very safe or use a method like SLIP39 that lets you distribute your
 recovery code across multiple locations without relying on the safety of
@@ -1026,7 +1026,7 @@ her family to recover the cryptocurrency((("wallets", "recovery codes", startref
 
 HD wallets ((("wallets", "key generation", "HD (hierarchical deterministic)", id="wallet-keygen-hd")))((("key generation", "HD (hierarchical deterministic)", id="keygen-hd")))((("HD (hierarchical deterministic) key generation", id="hd-keygen")))((("BIP32 HD (hierarchical deterministic) key generation", id="bip32")))((("seeds", "HD wallet creation", id="seed-hdwallet")))are created from a ((("root seeds")))single _root seed_, which is a
 128-, 256-, or 512-bit random number. Most commonly, this seed is
-generated by or decrypted from a _recovery code_ as detailed in the previous section.
+generated by or decrypted from a recovery code as detailed in the previous section.
 
 Every key in the HD wallet is deterministically derived from this root
 seed, which makes it possible to re-create the entire HD wallet from
@@ -1068,7 +1068,7 @@ that combines:
 The chain code is used to introduce deterministic random data to the
 process, so that knowing the index and a child key is not sufficient to
 derive other child keys. Knowing a child key does not make it possible
-to find its siblings, unless you also have the chain code. The initial
+to find its siblings unless you also have the chain code. The initial
 chain code seed (at the root of the tree) is made from the seed, while
 subsequent child chain codes are derived from each parent chain code.
 
@@ -1089,7 +1089,7 @@ parent.
 image::images/mbc3_0507.png["ChildPrivateDerivation"]
 
 Changing the index allows us to extend the parent and create the other
-children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each
+children in the sequence (e.g., Child 0, Child 1, Child 2, etc.). Each
 parent key can have 2,147,483,647 (2^31^) children (2^31^ is half of the
 entire 2^32^ range available because the other half is reserved for a
 special type of derivation we will talk about later in this chapter).
@@ -1177,9 +1177,9 @@ LrtJunSDMstweyLXhRgPxdp14sk9tJPW9
 
 As
 mentioned  previously, ((("key generation", "HD (hierarchical deterministic)", "public child key derivation", id="keygen-hd-public-child")))((("HD (hierarchical deterministic) key generation", "public child key derivation", id="hd-keygen-public-child")))((("public child key derivation", id="public-child")))((("child key pair derivation", "public keys", id="child-key-pair-public")))a very useful characteristic of HD wallets is the
-ability to derive public child keys from public parent keys, _without_
+ability to derive public child keys from public parent keys _without_
 having the private keys. This gives us two ways to derive a child public
-key: either from the child private key, or directly from the parent
+key: either from the child private key or directly from the parent
 public key.
 
 An extended public key can be used, therefore, to derive all of the
@@ -1189,7 +1189,7 @@ structure.
 This shortcut can be used to create public key–only
 deployments where a server or application has a copy of an extended
 public key and no private keys whatsoever. That kind of deployment can
-produce an infinite number of public keys and Bitcoin addresses, but
+produce an infinite number of public keys and Bitcoin addresses but
 cannot spend any of the money sent to those addresses. Meanwhile, on
 another, more secure server, the extended private key can derive all the
 corresponding private keys to sign transactions and spend the money.
@@ -1359,9 +1359,9 @@ a "gap" in the tree above the level where extended public keys are used.
 
 In simple terms, if you want to use the convenience of an xpub to derive
 branches of public keys, without exposing yourself to the risk of a
-leaked chain code, you should derive it from a hardened parent, rather
+leaked chain code, you should derive it from a hardened parent rather
 than a normal parent. As a best practice, the level-1 children of the
-master keys are always derived through the hardened derivation, to
+master keys are always derived through the hardened derivation to
 prevent compromise of the master keys.
 
 ===== Index numbers for normal and hardened derivation
@@ -1445,7 +1445,7 @@ extended key can have 4 billion children: 2 billion normal children and
 billion children, and so on. The tree can be as deep as you want, with
 an infinite number of generations. With all that flexibility, however,
 it becomes quite difficult to navigate this infinite tree. It is
-especially difficult to transfer HD wallets between implementations,
+especially difficult to transfer HD wallets between implementations
 because the possibilities for internal organization into branches and
 subbranches are endless.
 
@@ -1456,7 +1456,7 @@ the "purpose" of the tree structure. Based on BIP43, an HD wallet
 should use only one level-1 branch of the tree, with the index number
 identifying the structure and namespace of the rest of the tree by
 defining its purpose. For example, an HD wallet using only branch
-m/i++&#x27;++/ is intended to signify a specific purpose and that
+m/i++&#x27;++/ is intended to signify a specific purpose, and that
 purpose is identified by index number "i."
 
 Extending that specification, ((("BIP44 HD wallet tree structure", id="bip44")))BIP44 proposes a multiaccount structure
@@ -1474,10 +1474,10 @@ The first-level "purpose" is always set to +44'+. The second-level
 "coin_type" specifies the type of cryptocurrency coin, allowing for
 multicurrency HD wallets where each currency has its own subtree under
 the second level.  Bitcoin is
-m/44'/0' and Bitcoin Testnet is m/44++&#x27;++/1++&#x27;++.
+m/44'/0' and Bitcoin Testnet is m/44++&#x27;++/1++'++.
 
 The third level of the tree is "account," which allows users to
-subdivide their wallets into separate logical subaccounts, for
+subdivide their wallets into separate logical subaccounts for
 accounting or organizational purposes. For example, an HD wallet might
 contain two Bitcoin "accounts": m/44++&#x27;++/0++&#x27;++/0++&#x27;++
 and m/44++&#x27;++/0++&#x27;++/1++&#x27;++. Each account is the root of

ch06_transactions.adoc

@@ -54,7 +54,7 @@ e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
 
 Bitcoin Core's serialization format is special because it's the format
 used to make commitments to transactions and to relay them across
-Bitcoin's peer-to-peer (P2P) network, but otherwise programs can use
+Bitcoin's P2P network, but otherwise programs can use
 a different format as long as they transmit all of the
 same data.  However, Bitcoin Core's format is reasonably compact for the
 data it transmits and simple to parse, so many other Bitcoin programs
@@ -62,12 +62,12 @@ use this format.
 
 [TIP]
 ====
-The only ((("partially signed bitcoin transaction (PSBT) format")))((("PSBT (partially signed bitcoin transaction) format")))other widely used transaction serialization format of that
+The only ((("partially signed bitcoin transaction (PSBT) format")))((("PSBT (partially signed bitcoin transaction) format")))other widely used transaction serialization format that
 we're aware of is the partially signed bitcoin transaction (PSBT) format
 documented in BIPs 174 and 370 (with extensions documented in other
 BIPs).  PSBT allows an untrusted program to produce a transaction
 template that can be verified and updated by trusted programs (such as
-hardware signing devices) that possesses the necessary private keys or
+hardware signing devices) that have the necessary private keys or
 other sensitive data to fill in the template.  To accomplish this, PSBT
 allows storing a significant amount of metadata about a transaction,
 making it much less compact than the standard serialization format.
@@ -135,7 +135,7 @@ If you implement a protocol that uses presigned transactions, ensure
 that it doesn't use any features that are reserved for future upgrades.
 Bitcoin Core's default transaction relay policy does not allow the use
 of reserved features.  You can test whether a transaction complies with
-that policy by using the Bitcoin Core RPC +testmempoolaccept+ on ((("transactions", "presigned", startref="transaction-presign")))((("presigned transactions", startref="presign-transaction")))Bitcoin
+that policy by using Bitcoin Core's +testmempoolaccept+ RPC on ((("transactions", "presigned", startref="transaction-presign")))((("presigned transactions", startref="presign-transaction")))Bitcoin
 mainnet.
 ****
 
@@ -143,8 +143,8 @@ As of this writing, a proposal to begin using version 3 transactions is
 being widely considered.  That proposal does not seek to change the
 consensus rules but only the policy that Bitcoin full nodes use to relay
 transactions.  Under the proposal, version 3 transactions would be
-subject to additional constraints in order to prevent certain Denial of
-Service (DoS) attacks that we'll discuss((("transactions", "version of", startref="transactions-version")))((("version (of transactions)", startref="version-transactions"))) further in <<transaction_pinning>>.
+subject to additional constraints in order to prevent certain denial of
+service (DoS) attacks that we'll discuss((("transactions", "version of", startref="transactions-version")))((("version (of transactions)", startref="version-transactions"))) further in <<transaction_pinning>>.
 
 === Extended Marker and Flag
 
@@ -262,7 +262,7 @@ Each input in a transaction must contain three fields:
 
 We'll look at each of those fields in the following sections.  Some
 inputs also include a witness stack, but this is serialized at the end of a
-transaction and so we'll ((("transactions", "inputs", "length of list", startref="transaction-input-length")))((("inputs", "length of list", startref="input-transaction-length")))examine it later.
+transaction so we'll ((("transactions", "inputs", "length of list", startref="transaction-input-length")))((("inputs", "length of list", startref="input-transaction-length")))examine it later.
 
 
 [[outpoints]]
@@ -347,7 +347,7 @@ txid from the outpoint in our example transaction:
 eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a
 ----
 
-If we try using that that txid to retrieve that transaction using
+If we try using that txid to retrieve that transaction using
 Bitcoin Core, we get an error and must reverse its byte order:
 
 ----
@@ -371,7 +371,7 @@ This odd behavior is probably an unintentional consequence of a
 https://oreil.ly/01JH2[design
 decision in early Bitcoin software].  As a practical matter, it means
 developers of Bitcoin software need to remember to reverse the order of
-bytes in transaction and block identifiers that they show to users.
+bytes in transaction and block identifiers they show to users.
 
 In this book, we use the term _internal byte order_ for the data that
 appears within transactions and blocks.  We use _display byte order_ for
@@ -486,7 +486,7 @@ isn't a very effective protocol.
 The third problem was that it was possible to replace one version of a
 transaction with a different version an unlimited number of
 times.  Each replacement would consume the bandwidth of all the relaying full nodes
-on the network.  For example, as of this writing there are about 50,000
+on the network.  For example, as of this writing, there are about 50,000
 relaying full nodes; an attacker creating 1,000 replacement transactions
 per minute at 200 bytes each would use about 20 kilobytes of their
 personal bandwidth but about 10 gigabytes of full node network bandwidth
@@ -546,7 +546,7 @@ Since sequence is a per-input field, a transaction may contain any
 number of timelocked inputs, all of which must have sufficiently aged
 for the transaction to be valid. A disable flag allows a transaction to
 include both inputs with a relative timelock (sequence < 2^31^) and
-inputs without a relative timelock (sequence >= 2^31^).
+inputs without a relative timelock (sequence ≥ 2^31^).
 
 The sequence value is specified in either blocks or seconds.
 A type-flag
@@ -573,7 +573,7 @@ as defined by BIP68.
 .BIP68 definition of sequence encoding (Source: BIP68)
 image::images/mbc3_0603.png["BIP68 definition of sequence encoding"]
 
-Note that any transaction which sets a relative timelock using sequence
+Note that any transaction that sets a relative timelock using sequence
 also sends the signal for opt-in replace by fee ((("transactions", "inputs", startref="transaction-input")))((("inputs", startref="input-transaction")))((("transactions", "inputs", "sequence field", startref="transaction-input-sequence")))((("inputs", "sequence field", startref="input-transaction-sequence")))((("sequence field (transaction inputs)", startref="sequence-field")))((("relative timelocks", startref="relative-timelock")))as described in
 <<sequence-bip125>>.
 
@@ -626,7 +626,7 @@ contribute any value to a transaction spending it even if the
 transaction's fee rate was zero.  However, many other outputs with low
 values can be uneconomical as well, even unintentionally.  For example,
 at a typical fee rate on the network today, an output might add more
-value to a transaction than it costs to spend--but, tomorrow, fee rates
+value to a transaction than it costs to spend--but tomorrow, fee rates
 might rise and make the output uneconomical.
 
 The need for full nodes to keep track of all unspent transaction outputs
@@ -685,7 +685,7 @@ satoshis aren't being ((("transactions", "outputs", "amount field", startref="tr
 
 The ((("transactions", "outputs", "output scripts", id="transaction-output-script")))((("outputs", "output scripts", id="output-transaction-script")))((("output scripts", id="output-script2")))output amount is followed by a compactSize integer indicating the
 length of the _output script_, the script that contains the
-conditions which will need to be fulfilled in order to spend the
+conditions that will need to be fulfilled in order to spend the
 bitcoins.  According to Bitcoin's
 consensus rules, the minimum size of an output script is zero.
 
@@ -703,7 +703,7 @@ the block containing it.
 An output script with zero length can be spent by an input script containing
 ++OP_TRUE++.  Anyone can create that input script, which means anyone
 can spend an empty output script.  There are an essentially unlimited
-number of scripts that anyone can spend and they are known to Bitcoin
+number of scripts that anyone can spend, and they are known to Bitcoin
 protocol developers as _anyone can spends_.  Upgrades to Bitcoin's
 script language often take an existing anyone-can-spend script and add
 new constraints to it, making it only spendable under the new
@@ -719,7 +719,7 @@ transaction outputs_.  This was originally implemented after the
 discovery of several early bugs in Bitcoin related to the Script
 language and is retained in modern Bitcoin Core to support
 anyone-can-spend upgrades and to encourage the best practice of placing
-script conditions in P2SH redeem script, segwit v0 witness scripts, and
+script conditions in P2SH redeem scripts, segwit v0 witness scripts, and
 segwit v1 (taproot) leaf scripts.
 
 We'll look at each of the current standard transaction templates and
@@ -736,7 +736,7 @@ accept evidence from those who are reliable.
 Imagine what a witness would look like for a math problem.  For example,
 if the important problem was _x + 2 == 4_ and someone claimed they
 witnessed the solution, what would we ask them?  We'd want a
-mathematical proof that showed a value which could be summed with two to
+mathematical proof that showed a value that could be summed with two to
 equal four.  We could even omit the need for a person and just use the
 proposed value for _x_ as our witness.  If we were told that the witness
 was _two_, then we could fill in the equation, check that it was correct, and
@@ -757,7 +757,7 @@ protected by the following script:
 Obviously, allowing your bitcoins to be spent by anyone who can solve a
 simple equation wouldn't be secure.  As we'll see in <<c_signatures>>, an
 unforgeable digital signature scheme uses an equation that can only be
-solved by someone in possession of certain data that they're able to
+solved by someone in possession of certain data they're able to
 keep secret.  They're able to reference that secret data using a public
 identifier.  That public identifier is ((("public keys")))((("digital signatures")))((("signatures", see="digital signatures")))called a _public key_ and a
 solution to the equation is called a _signature_.
@@ -797,7 +797,7 @@ transactions out of order:
 
 - If Alice and Bob sign Tx~1~ before they sign Tx~0~, then they're both
   guaranteed to be able to get a refund at any time.  The protocol
-  doesn't require either of them trust the other, making ((("trustless protocols")))it a _trustless
+  doesn't require either of them to trust the other, making ((("trustless protocols")))it a _trustless
   protocol_.
 
 A problem with this construction in the legacy transaction format is
@@ -882,7 +882,7 @@ developers worked on proposals to minimize third-party malleability,
 such as BIP62.  However, even if they were able to entirely eliminate
 third-party malleability, users of contract protocols faced another problem:
 if they required a signature from someone else involved in the protocol,
-that person could generate alternative signatures and so change the txid.
+that person could generate alternative signatures and change the txid.
 
 For example, Alice and Bob have deposited their money into a script
 requiring a signature from both of them to spend.  They've also created
@@ -1030,7 +1030,7 @@ items_.  We'll explore them in detail in
 each witness item is prefixed by a compactSize integer indicating its
 size.
 
-Legacy inputs don't contain any witness items so their witness stack
+Legacy inputs don't contain any witness items, so their witness stack
 consists entirely of a count of zero (0x00).
 
 Alice's transaction contains one input and one ((("transactions", "witnesses", startref="transaction-witness")))((("witnesses", startref="witness")))((("transactions", "witnesses", "count", startref="transaction-witness-count")))((("witnesses", "count", startref="witness-count")))witness item.
@@ -1039,7 +1039,7 @@ Alice's transaction contains one input and one ((("transactions", "witnesses", s
 === Lock Time
 
 The ((("transactions", "lock time")))((("lock time")))final field in a serialized transaction is its lock time.  This
-field was part of Bitcoin's original serialization format but it was
+field was part of Bitcoin's original serialization format, but it was
 initially only enforced by Bitcoin's policy for choosing which
 transactions to mine.  Bitcoin's earliest known soft fork added a rule
 that, starting at block height 31,000, forbid the inclusion of a

ch07_authorization-authentication.adoc

@@ -7,7 +7,7 @@ nodes will distinguish the authorized spenders from everyone else,
 called _authentication_.  Your authorization instructions and the
 spender proof of authentication will be checked by thousands of
 independent full nodes, which all need to come to the same conclusion
-that a spend was authorized and authentic in order for the transaction
+that a spend was authorized and authenticated in order for the transaction
 containing it to be valid.
 
 The original description of Bitcoin used a public key for authorization.
@@ -51,7 +51,7 @@ conditions for spending and how those conditions can be satisfied.
 [TIP]
 ====
 Bitcoin transaction validation((("transactions", "validating")))((("validating", "transactions"))) is not based on
-a static pattern, but instead is achieved through the execution of a
+a static pattern but instead is achieved through the execution of a
 scripting language. This language allows for a nearly infinite variety
 of conditions to be expressed.
 ====
@@ -75,7 +75,7 @@ validation mechanism from being used as a vulnerability.
 ==== Stateless Verification
 
 The ((("scripts", "stateless verification")))((("stateless script verification")))((("verifying", "scripts")))Bitcoin transaction script language is
-stateless, in that there is no state prior to execution of the script,
+stateless, in that there is no state prior to execution of the script
 or state saved after execution of the script. All the
 information needed to execute a script is contained within the script
 and the transaction executing the script.  A
@@ -112,7 +112,7 @@ validation software will copy the input script, retrieve the UTXO
 referenced by the input, and copy the output script from that UTXO. The
 input and output scripts are then executed together. The input is
 valid if the input script satisfies the output script's conditions
-(see <<script_exec>>). All the inputs are validated independently, as
+(see <<script_exec>>). All the inputs are validated independently as
 part of the overall validation of the transaction.
 
 Note that the preceding steps involve making copies of all data.  The
@@ -150,8 +150,8 @@ the stack.
 Conditional operators evaluate a condition, producing a boolean result
 of +TRUE+ or +FALSE+. For example, +OP_EQUAL+ pops two items from the stack
 and pushes +TRUE+ (+TRUE+ is represented by the number 1) if they are equal
-or +FALSE+ (represented by zero) if they are not equal. Bitcoin
-transaction scripts usually contain a conditional operator, so that they
+or +FALSE+ (represented by 0) if they are not equal. Bitcoin
+transaction scripts usually contain a conditional operator so that they
 can produce the +TRUE+ result that signifies a valid ((("scripts", "stack", startref="script-stack")))((("stack", startref="stack")))transaction.
 
 ===== A simple script
@@ -363,7 +363,7 @@ the input script has
 two valid signatures from private keys that correspond to two of
 the three public keys set as an encumbrance.
 
-At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most three
+At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to, at most, three
 listed public keys, meaning you can do anything from a 1-of-1 to a
 3-of-3 multisignature or any combination within that range.
 You may want to check the +IsStandard()+ function to see what is currently
@@ -400,13 +400,12 @@ point, +OP_CHECKMULTISIG+ should pop the final +t+ items, which are the
 signatures, and see if they are valid. However, unfortunately, an oddity in
 the implementation causes +OP_CHECKMULTISIG+ to pop one more item (t+1
 total) than it should. The extra item is called((("dummy stack element"))) the _dummy stack
-element_ and it is disregarded when checking the
+element_, and it is disregarded when checking the
 signatures so it has no direct effect on +OP_CHECKMULTISIG+ itself.
-However, the dummy element must be present because, if it isn't present,
+However, the dummy element must be present because, if it isn't present
 when +OP_CHECKMULTISIG+ attempts to pop on an empty stack, it will cause a
 stack error and script failure (marking the transaction as invalid).
-Because the dummy element is disregarded it can be anything, but
-it became the custom early on to use +OP_0+, which later became a
+Because the dummy element is disregarded, it can be anything. It became the custom early on to use +OP_0+, which later became a
 relay policy rule and eventually a consensus rule (with the enforcement of BIP147).
 
 Because popping the dummy element is part of the consensus rules, it must now be
@@ -448,9 +447,9 @@ indicating which provided signature corresponds to which public key,
 allowing the +OP_CHECKMULTISIG+ operation to only perform exactly +t+
 signature-checking operations.  It's possible that Bitcoin's original
 developer added the extra element (which we now call the dummy stack
-element) in the original version of Bitcoin so that they could add the
+element) in the original version of Bitcoin so they could add the
 feature for allowing a map to be passed in a later soft fork.  However,
-that feature was never implemented and the BIP147 update to the
+that feature was never implemented, and the BIP147 update to the
 consensus rules in 2017 makes it impossible to add that feature in the
 future.
 
@@ -552,10 +551,10 @@ with P2SH.
 </table>
 ++++
 
-As you can see from the tables, with P2SH the complex script that
+As you can see from the tables, with P2SH, the complex script that
 details the conditions for spending the output (redeem script) is not
 presented in the output script. Instead, only a hash of it is in the
-output script and the redeem script itself is presented later, as part
+output script, and the redeem script itself is presented later as part
 of the input script when the output is spent. This shifts the burden
 in fees and complexity from the spender to the receiver of the
 transaction.
@@ -572,7 +571,7 @@ incoming payments from customers:
 ----
 
 This entire script can instead be represented by a 20-byte cryptographic
-hash, by first applying the SHA256 hashing algorithm and then applying
+hash by first applying the SHA256 hashing algorithm and then applying
 the RIPEMD-160 algorithm on the result.  For example, starting with the
 hash of Mohammed's redeem script:
 
@@ -625,14 +624,14 @@ base58check-encoded addresses that start with a "3."
 For example, Mohammed's complex script, hashed and base58check-encoded
 as a P2SH address, becomes +39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw+.
 
-Now, Mohammed can give this "address" to his customers and they can use
-almost any Bitcoin wallet to make a simple payment, like any other
+Now, Mohammed can give this "address" to his customers, and they can use
+almost any Bitcoin wallet to make a simple payment like any other
 Bitcoin address. The 3 prefix gives them a hint that this is a special
 type of address, one corresponding to a script instead of a public key,
 but otherwise it works in exactly the same way as a payment to any other Bitcoin
 address.
 
-P2SH addresses hide all of the complexity so that the person making a
+P2SH addresses hide all of the complexity so the person making a
 payment does not see the script.
 
 ==== Benefits of P2SH
@@ -657,7 +656,7 @@ scripts in outputs:
 
 ==== Redeem Script and Validation
 
-You are((("redeem scripts", "validating")))((("validating", "redeem scripts"))) not able to put a P2SH inside a P2SH redeem script, because the
+You are((("redeem scripts", "validating")))((("validating", "redeem scripts"))) not able to put a P2SH inside a P2SH redeem script because the
 P2SH specification is not recursive. Also, while it is technically
 possible to include +OP_RETURN+ (see <<op_return>>) in a redeem script, as
 nothing in the rules prevents you from doing so, it is of no practical
@@ -669,7 +668,7 @@ until you attempt to spend a P2SH output, if you create an output with the
 hash of an invalid redeem script, you will not be able to spend
 it.  The spending transaction, which includes the redeem script,
 will not be accepted because it is an invalid script. This creates a
-risk, because you can send bitcoin to a P2SH address that cannot be spent later.
+risk because you can send bitcoin to a P2SH address that cannot be spent later.
 
 [WARNING]
 ====
@@ -742,7 +741,7 @@ Keep in mind that there is no input script that corresponds to
 whole point of an +OP_RETURN+ output is that you can't spend the money locked in that
 output, and therefore it does not need to be held in the UTXO set as
 potentially spendable: +OP_RETURN+ outputs are _provably unspendable_. +OP_RETURN+ outputs
-usually have a zero amount, because any bitcoins
+usually have a zero amount because any bitcoins
 assigned to such an output are effectively lost forever. If an +OP_RETURN+ output is
 referenced as an input in a transaction, the script validation engine
 will halt the execution of the validation script and mark the
@@ -759,7 +758,7 @@ being included in a block until a specific block height, but it does not
 prevent spending the funds in another transaction earlier than that.
 Let's explain that with the following example.
 
-Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
+Alice signs a transaction spending one of her outputs to Bob's address and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
 
 * Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed.
 * Bob may transmit the transaction after 3 months.
@@ -777,7 +776,7 @@ In ((("transactions", "timelocks", "verifying", id="transaction-timelock-op-cltv
 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_CLTV+ is a per-output timelock, rather than a per-transaction timelock
++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.
 
@@ -808,7 +807,7 @@ To lock it to a time, say 3 months from now, his P2SH script would
 instead be:
 
 ----
-<Bob's pubkey> OP_CHECKSIGVERIFY <now + 3 months> OP_CHECKLOCKTIMEVERIFYG
+<Bob's pubkey> OP_CHECKSIGVERIFY <now + 3 months> OP_CHECKLOCKTIMEVERIFY
 ----
 
 where +<now {plus} 3 months>+ is a block height or time value estimated
@@ -823,7 +822,7 @@ to be equal or greater to the timelock in the +OP_CHECKLOCKTIMEVERIFY+
 Alice set. Bob then broadcasts the transaction on the Bitcoin network.
 
 Bob's transaction is evaluated as follows. If the +OP_CHECKLOCKTIMEVERIFY+
-parameter Alice set is less than or equal the spending transaction's
+parameter Alice set is less than or equal to the spending transaction's
 lock time, script execution continues (acts as if a _no
 operation_ or +OP_NOP+ opcode was executed). Otherwise, script
 execution halts and the transaction is deemed invalid.
@@ -911,7 +910,7 @@ the +OP_CHECKSEQUENCEVERIFY+ (+OP_CSV+) opcode.
 Relative timelocks are
 implemented according to the specifications in
 https://oreil.ly/ZuANb[BIP68,
-Relative lock-time using consensus-enforced sequence numbers] and
+relative lock-time using consensus-enforced sequence numbers] and
 https://oreil.ly/dLA2r[BIP112,
 +OP_CHECKSEQUENCEVERIFY+].
 
@@ -947,7 +946,7 @@ of interaction across inputs that occurs with +OP_CLTV+ doesn't affect +OP_CSV+.
 ====
 
 Relative timelocks with +OP_CSV+ are especially useful when several
-(chained) transactions are created and signed, but not propagated--that
+(chained) transactions are created and signed but not propagated--that
 is, they're kept off the blockchain (_offchain_). A child transaction cannot be used until the
 parent transaction has been propagated, mined, and aged by the time
 specified in the relative timelock. One application of this use case is shown in <<state_channels>> and <<lightning_network>>.
@@ -962,7 +961,7 @@ One of((("scripts", "flow control", id="script-flow")))((("flow control in scrip
 powerful features of Bitcoin Script is flow control, also known as
 conditional clauses. You are probably familiar with flow control in
 various programming languages that use the construct +IF...THEN...ELSE+.
-Bitcoin conditional clauses look a bit different, but are essentially
+Bitcoin conditional clauses look a bit different but are essentially
 the same construct.
 
 At a basic level, Bitcoin conditional opcodes allow us to construct a
@@ -1082,7 +1081,7 @@ A very common use for flow control in Bitcoin Script is to construct a
 script that offers multiple execution paths, each a different way
 of redeeming the UTXO.
 
-Let's look at a simple example, where
+Let's look at a simple example where
 we have two signers, Alice and Bob, and either one is able to redeem.
 With multisig, this would be expressed as a 1-of-2 multisig script. For
 the sake of demonstration, we will do the same thing with an +OP_IF+
@@ -1146,7 +1145,7 @@ In this scenario, there are three execution paths (+subscript A+, +subscript
 B+, and +subscript C+). The input script provides a path in the form of
 a sequence of +TRUE+ or +FALSE+ values. To select path +subscript B+, for
 example, the input script must end in +OP_1 OP_0+ (+TRUE+, +FALSE+). These
-values will be pushed onto the stack, so that the second value (+FALSE+)
+values will be pushed onto the stack so that the second value (+FALSE+)
 ends up at the top of the stack. The outer +OP_IF+ clause pops the +FALSE+
 value and executes the first +OP_ELSE+ clause. Then the +TRUE+ value moves
 to the top of the stack and is evaluated by the inner (nested) +OP_IF+,
@@ -1163,7 +1162,7 @@ at each flow control((("scripts", "flow control", startref="script-flow")))((("f
 In this((("scripts", "examples of", id="script-example-complex"))) section we combine many of
 the concepts from this chapter into a single example.
 
-Mohammed is company owner in Dubai who is operating an import/export
+Mohammed, a company owner in Dubai, operates an import/export
 business; he
 wishes to construct a company capital account with flexible rules. The
 scheme he creates requires different levels of authorization depending
@@ -1239,7 +1238,7 @@ OP_0 <Saeed's Sig> <Lawer's Sig> OP_FALSE OP_TRUE
 [TIP]
 ====
 Why +OP_FALSE OP_TRUE+? Isn't that backward? +FALSE+ is pushed onto the
-stack and +TRUE+ is pushed on top of it.
+stack, and +TRUE+ is pushed on top of it.
 +TRUE+ is therefore popped _first_ by the first +OP_IF+ opcode.
 ====
 
@@ -1480,14 +1479,14 @@ Alice and Bob can use legacy non-segwit outputs. But Bob would
 likely want to use segwit to reduce transaction fees, taking advantage
 of the reduced cost of witness structure.
 
-In this case Bob's wallet can construct a P2SH address that contains a
+In this case, Bob's wallet can construct a P2SH address that contains a
 segwit script inside it. Alice's wallet can make payments to it without
 any knowledge of segwit.
 Bob's wallet can then spend this payment with a segwit transaction,
 taking advantage of segwit and reducing transaction fees.
 
 Both forms of witness scripts, P2WPKH and P2WSH, can be embedded in a
-P2SH address. The first is noted as nested P2WPKH and the second is noted
+P2SH address. The first is noted as nested P2WPKH, and the second is noted
 as nested P2WSH.
 
 ===== Nested pay to witness public key hash
@@ -1632,7 +1631,7 @@ image::images/mbc3_0705.png["A MAST with three sub-scripts"]
 We can now create a compact membership proof that proves a particular
 authorization condition is a member of the merkle tree without
 disclosing any details about the other members of the merkle tree.  See
-<<diagram_mast2>>, and note that the nodes with diagonal corners can be
+<<diagram_mast2>>, and note that the shaded nodes can be
 computed from other data provided by the user, so they don't need to be
 specified at spend time.
 
@@ -1641,7 +1640,7 @@ specified at spend time.
 image::images/mbc3_0706.png["A MAST membership proof for one of the sub-scripts"]
 
 The hash digests used to create the commitments are each 32 bytes, so
-proving a spend of <<diagram_mast2>> is authorized (using a merkle tree and the
+proving that a spend of <<diagram_mast2>> is authorized (using a merkle tree and the
 particular conditions) and authenticated (using signatures) uses 383
 bytes.  By comparison, the same spend without a merkle tree (i.e., providing all possible authorization conditions) uses 412 bytes.
 
@@ -1692,7 +1691,7 @@ discovered, which we'll see in <<taproot>>.
 .MAST Versus MAST
 ****
 The earliest((("abstract syntax trees (AST)")))((("AST (abstract syntax trees)"))) idea for what we now know as _MAST_ in Bitcoin was
-_merklized abstract syntax trees_.  In an absract syntax tree (AST),
+_merklized abstract syntax trees_.  In an abstract syntax tree (AST),
 every condition in a script creates a new branch, as show in <<ast>>.
 
 [[ast]]
@@ -1701,12 +1700,12 @@ image::images/mbc3_0708.png["An Abstract Syntax Tree (AST) for a script"]
 
 ASTs are widely used by programs that parse and optimize code for other
 programs, such as compilers.  A merklized AST would commit to every part
-of a program and so enable the features described in 
+of a program and enable the features described in 
 <<mast>>, but it would require revealing at least one 32-byte digest for
 every separate part of the program, which would not be very space
 efficient on the blockchain for most programs.
 
-What most people in most cases call _MAST_ in Bitcoin today is
+What people in most cases call _MAST_ in Bitcoin today is
 _merklized alternative script trees_, a backronym coined by developer
 Anthony Towns.  An alternative script tree is a set of scripts, each
 one of them complete by itself, where only one can be selected--making
@@ -1737,22 +1736,22 @@ also serve another use.
 
 Let's imagine Bob wants to buy something from Alice but he also wants to
 be able prove later what he paid for in case there's any dispute.  Alice
-and Bob agree on the name of the item or service being sold, e.g.,
-"Alice's podcast episode #123," and transform that description into a
+and Bob agree on the name of the item or service being sold (e.g.,
+"Alice's podcast episode #123"), and transform that description into a
 number by hashing it and interpreting the hash digest as a number.  Bob
 adds that number to Alice's public key and pays it.  The process is
-called _key tweaking_ and the number is known as a _tweak_.
+called _key tweaking_, and the number is known as a _tweak_.
 
 Alice can spend the funds by tweaking her private key using the same
 number (tweak).
 
 Later, Bob can prove to anyone what he paid Alice by revealing her
 underlying key and the description they used.  Anyone can verify that
-the public key which was paid equals the underlying key plus the
+the public key, which was paid, equals the underlying key plus the
 hash commitment to the description.  If Alice admits that key is hers,
 then she received the payment.  If Alice spent the funds, this further
 proves she knew the description at the time she signed the spending
-transaction, since she could only create a valid signature for the
+transaction since she could only create a valid signature for the
 tweaked public key if she knew the tweak (the description).
 
 If neither Alice nor Bob decided to publicly reveal the description they
@@ -1808,7 +1807,7 @@ using a single key and signature.  The story is the same for privacy:
 because each new key or signature adds data to a transaction, scripted
 multisignatures disclose data about how many keys and signatures are
 being used--which may make it easy to figure out which transactions were
-created by which group of participants.  But, because every scriptless
+created by which group of participants.  However, because every scriptless
 multisignatures looks like every other scriptless
 multisignature and every single-signature, no privacy-reducing data is
 leaked.

ch08_signatures.adoc

@@ -92,7 +92,7 @@ signature on this transaction."
 
 Digital signatures((("digital signatures", "SIGHASH flags", id="digital-signature-sighash")))((("SIGHASH flags", id="sighash"))) apply to messages,
 which in the case of Bitcoin, are the transactions themselves. The
-signature prove a _commitment_ by the signer to specific transaction
+signature proves a _commitment_ by the signer to specific transaction
 data. In the simplest form, the signature applies to almost the entire
 transaction, thereby committing to all the inputs, outputs, and other
 transaction fields. However, a signature can commit to only a subset of
@@ -103,7 +103,7 @@ Bitcoin signatures have a way of indicating which
 part of a transaction's data is included in the hash signed by the
 private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte
 that is appended to the signature. Every signature has either an
-explicit or implicit +SIGHASH+ flag
+explicit or implicit +SIGHASH+ flag,
 and the flag can be different from input to input. A transaction with
 three signed inputs may have three signatures with different +SIGHASH+
 flags, each signature signing (committing) to different parts of the
@@ -217,7 +217,7 @@ in practice:
 funds can construct a transaction with a single output. The single
 output pays the "goal" amount to the fundraiser. Such a transaction is
 obviously not valid, as it has no inputs. However, others can now amend
-it by adding an input of their own, as a donation. They sign their own
+it by adding an input of their own as a donation. They sign their own
 input with +ALL|ANYONECANPAY+. Unless enough inputs are gathered to
 reach the value of the output, the transaction is invalid. Each donation
 is a "pledge," which cannot be collected by the fundraiser until the
@@ -227,7 +227,7 @@ someone who lends them funds), allowing them to collect the donations
 even if they haven't reached the specified value.
 
 +NONE+ :: This construction can be used to create a "bearer check" or
-"blank check" of a specific amount. It commits to all inputs, but allows
+"blank check" of a specific amount. It commits to all inputs but allows
 the outputs to be changed. Anyone can write their own
 Bitcoin address into the output script.
 By itself, this allows any miner to change
@@ -394,7 +394,7 @@ generator +G=5+ to get her public key +xG=15+.  She gives Bob +15+.
 
 4. Bob derives +sG = 200 = 40 * 5+ and +exG = 165 = 11 * 15+.  He then
   verifies that +200 == 35 + 165+.  Note that this is the same operation
-  that Alice performed but all of the values have been scaled up by +5+
+  that Alice performed, but all of the values have been scaled up by +5+
   (the value of +G+).
 
 Of course, this is an oversimplified example.  When working with simple
@@ -549,8 +549,7 @@ she's ready to spend, she begins generating her signature:
 ==== Serialization of Schnorr Signatures
 
 A schnorr signature ((("digital signatures", "schnorr signature algorithm", "serialization")))((("schnorr signature algorithm", "serialization")))((("serialization", "of schnorr signature algorithm", secondary-sortas="schnorr")))consists of two values, +kG+ and +s+.  The value
-+kG+ is a point on Bitcoin's elliptic curve (called secp256k1) and so
-would normally be represented by two 32-byte coordinates, e.g., +(x,y)+.
++kG+ is a point on Bitcoin's elliptic curve (called secp256k1) and would normally be represented by two 32-byte coordinates, e.g., +(x,y)+.
 However, only the _x_ coordinate is needed, so only that value is
 included.  When you see +kG+ in schnorr signatures for Bitcoin, note that it's only that point's _x_
 coordinate.
@@ -560,7 +559,7 @@ Bitcoin's secp256k1 curve, it can never be more than 32 bytes long.
 
 Although both +kG+ and +s+ can sometimes be values that can be
 represented with fewer than 32 bytes, it's improbable that they'd be
-much smaller than 32 bytes, and so they're serialized as two 32-byte
+much smaller than 32 bytes, so they're serialized as two 32-byte
 values (i.e., values smaller than 32 bytes have leading zeros).
 They're serialized in the order of +kG+ and then +s+, producing exactly
 64 bytes.
@@ -621,9 +620,9 @@ simple multisignature protocol:
 
 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
-else.  The protocol can be extended to any number of participants; e.g.,
+else.  The protocol can be extended to any number of participants (e.g.,
 a million people could prove they knew the sum of their million
-different keys.
+different keys).
 
 The preceding protocol has several security problems.  Most notable is that one
 party might learn the public keys of the other parties before committing
@@ -631,7 +630,7 @@ to their own public key.  For example, Alice generates her public key
 +yG+ honestly and shares it with Bob.  Bob generates his public key
 using +zG - yG+.  When their two keys are combined (+yG + zG - yG+), the
 positive and negative +yG+ terms cancel out so the public key only represents
-the private key for +z+, i.e., Bob's private key.  Now Bob can create a
+the private key for +z+ (i.e., Bob's private key).  Now Bob can create a
 valid signature without any assistance from Alice.  This is ((("key cancellation attacks")))called a
 _key cancellation attack_.
 
@@ -790,9 +789,9 @@ work together to reconstruct Alice's partial private key.  Now Bob has
 his own partial private key plus the keys of Alice and Carol, allowing
 him to spend the funds himself without their involvement.  This attack can
 be addressed if all of the participants agree to only communicate using a
-scheme that allows any one of them to see all of the other's messages;
-e.g., if Bob tells Alice that Carol is unavailable, Carol is able to see
-that message before she begins working with Bob.  Other solutions,
+scheme that allows any one of them to see all of the other's messages
+(e.g., if Bob tells Alice that Carol is unavailable, Carol is able to see
+that message before she begins working with Bob).  Other solutions,
 possibly more robust solutions, to this problem were being researched at
 the time of writing.
 
@@ -841,7 +840,7 @@ Less provable security::
 
 Nonlinear::
   ECDSA signatures cannot be easily combined to create scriptless
-  multisignatures or used in related advanced applications such as
+  multisignatures or used in related advanced applications, such as
   multiparty signature adaptors.  There are workarounds for this
   problem, but they involve additional extra complexity that
   significantly slows down operations and which, in some cases, has
@@ -923,7 +922,7 @@ as follows:
 === The Importance of Randomness in Signatures
 
 As we((("digital signatures", "randomness, importance of", id="digital-signature-random")))((("randomness, importance in digital signatures", id="random-digital-signature"))) saw in <<schnorr_signatures>> and <<ecdsa_signatures>>,
-the signature generation algorithm uses a random number _k_, as the basis
+the signature generation algorithm uses a random number _k_ as the basis
 for a private/public nonce pair. The value of _k_ is not
 important, _as long as it is random_. If signatures from the same
 private key use the private nonce _k_ with different messages

ch09_fees.adoc

@@ -17,7 +17,7 @@ blockchain to a sufficient depth before he considers the money he
 received as his to spend (see <<confirmations>>).
 For Alice's transaction to be included in the
 blockchain, it must be included in a _block_ of transactions.  There are
-a limited number of((("blocks", "transactions in")))((("transactions", "in blocks", secondary-sortas="blocks"))) blocks produced in a given amount of time and each
+a limited number of((("blocks", "transactions in")))((("transactions", "in blocks", secondary-sortas="blocks"))) blocks produced in a given amount of time, and each
 block only has a limited amount of space.  Only the miner who creates
 that block gets to choose which transactions to include.  Miners may
 select transactions by any criteria they want, including refusing to
@@ -84,7 +84,7 @@ a payment typically have an interest in having it confirming quickly, so
 normally allowing only spenders to choose fees can sometimes be a
 problem; we'll look at a solution to that problem in <<cpfp>>.  However,
 in many common payment flows, the parties with the highest desire to see a
-transaction confirm quickly--that is, the parties who'd be the most
+transaction confirm quickly--that is, the parties who would be the most
 willing to pay higher fees--are the spenders.
 
 For those reasons, both technical and practical, it is customary in
@@ -230,11 +230,11 @@ Full RBF::
 ****
 The reason for the two different versions of RBF is that full RBF has
 been controversial.  Early versions of Bitcoin allowed transaction
-replacement but this behavior was disabled for several releases.  During
+replacement, but this behavior was disabled for several releases.  During
 that time, a miner or full node using the software now called Bitcoin
 Core would not replace the first version of an unconfirmed transaction
 they received with any different version.  Some merchants came to expect
-this behavior: they assumed that any valid unconfirmed transaction which
+this behavior: they assumed that any valid unconfirmed transaction that
 paid an appropriate fee rate would eventually become a confirmed
 transaction, so they provided their goods or services shortly after
 receiving such an unconfirmed transaction.
@@ -292,7 +292,7 @@ having "Sending support" on
 https://oreil.ly/IhMzx.
 
 As a developer, if you plan to implement RBF fee bumping, you will first
-need to decided whether to perform opt-in RBF or full RBF.  At the time
+need to decide whether to perform opt-in RBF or full RBF.  At the time
 of writing, opt-in RBF is the only method that's sure to work.  Even if
 full RBF becomes reliable, there will likely be several years where
 replacements of opt-in transactions get confirmed slightly faster than
@@ -432,7 +432,7 @@ The solution to this problem is the ability to relay transactions as a
 package, called _package relay_, allowing the receiving node to evaluate
 the fee rate of the entire package before operating on any individual
 transaction.  As of this writing, developers working on Bitcoin Core
-have made significant progress on implementing package relay and a
+have made significant progress on implementing package relay, and a
 limited early version of it may be available by the time this book is
 published.
 
@@ -594,10 +594,10 @@ Fees = Sum(Inputs) – Sum(Outputs)
 ----
 
 This is a somewhat confusing element of transactions and an important
-point to understand, because if you are constructing your own
-transactions you must ensure you do not inadvertently include a very
+point to understand because if you are constructing your own
+transactions, you must ensure you do not inadvertently include a very
 large fee by underspending the inputs. That means that you must account
-for all inputs, if necessary by creating change, or you will end up
+for all inputs, if necessary, by creating change, or you will end up
 giving the miners a very big tip!
 
 For example, if you spend a 20-bitcoin UTXO to make a 1-bitcoin
@@ -619,7 +619,7 @@ you intended.
 === Timelock Defense Against Fee Sniping
 
 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"
+attack scenario where miners attempting to rewrite past blocks "snipe"
 higher-fee transactions from future blocks to maximize their
 profitability.
 
@@ -635,7 +635,7 @@ They can include any transactions that were in the "old" block
 Essentially they have the option to pull transactions from the "present"
 into the rewritten "past" when they re-create block  #100,000.
 
-Today, this attack is not very lucrative, because the block subsidy is much
+Today, this attack is not very lucrative because the block subsidy is much
 higher than total fees per block. But at some point in the future,
 transaction fees will be the majority of the reward (or even the
 entirety of the reward). At that time, this scenario becomes inevitable.
@@ -649,15 +649,15 @@ no effect&#x2014;the transactions could only be included in block
 #100,001 anyway; it's the next block.
 
 But under a reorganization attack, the miners would not be able to pull
-high-fee transactions from the mempool, because all those transactions
+high-fee transactions from the mempool because all those transactions
 would be timelocked to block #100,001. They can only remine  #100,000
 with whatever transactions were valid at that time, essentially gaining
 no new fees.
 
 This does not entirely prevent fee sniping, but it does make it less
-profitable in some cases and so can help preserve the stability of the
+profitable in some cases and can help preserve the stability of the
 Bitcoin network as the block subsidy declines.  We recommend all wallets
-implement anti fee sniping when it doesn't interfere with the wallet's
+implement anti-fee sniping when it doesn't interfere with the wallet's
 other uses of the lock time field.
 
 As Bitcoin continues to mature, and as the subsidy continues to decline,

ch10_network.adoc

@@ -222,7 +222,7 @@ receive it.  For example:
 A third technique is to assume all nodes receiving the data have
 almost all of the same transactions in their mempool, so they can all
 accept the same compact block.  That not only saves us time computing
-a compact block at each hop, but it means that all each hop can simply
+a compact block at each hop, but it means that each hop can simply
 relay the FEC packets to the next hop even before validating them.
 
 The trade-off for each of the preceding methods is that they work well with
@@ -238,7 +238,7 @@ The original
 https://oreil.ly/30ZKi[Bitcoin Relay Network] was((("Bitcoin Relay Network"))) created by
 developer Matt Corallo in 2015 to enable fast synchronization of
 blocks between miners with very low latency. The network consisted of
-several Virtual Private Servers (VPSes) hosted on
+several virtual private servers (VPSes) hosted on
 infrastructure around the world and served to connect the majority of
 miners and mining pools.
 
@@ -268,7 +268,7 @@ information, including:
 +Version+:: The Bitcoin P2P protocol version the client "speaks" (e.g., 70002)
 +nLocalServices+:: A list of local services supported by the node
 +nTime+:: The current time
-+addrYou+:: The IP address of the remote node as seen from this node
++addrYou+:: The IP address of the remote node, as seen from this node
 +addrMe+:: The IP address of the local node, as discovered by the local node
 +subver+:: A subversion showing the type of software running on this node (e.g., [.keep-together]#+/Satoshi:0.9.2.1/+#)
 +BestHeight+:: The block height of this node's blockchain
@@ -326,12 +326,12 @@ A node must connect to a few different peers in order to establish
 diverse paths into the Bitcoin network. Paths are not reliable—nodes
 come and go—and so the node must continue to discover new nodes as it
 loses old connections as well as assist other nodes when they bootstrap.
-Only one connection is needed to bootstrap, because the first node can
+Only one connection is needed to bootstrap because the first node can
 offer introductions to its peer nodes and those peers can offer further
 introductions. It's also unnecessary and wasteful of network resources
 to connect to more than a handful of nodes. After bootstrapping, a node
-will remember its most recent successful peer connections, so that if it
-is rebooted it can quickly reestablish connections with its former peer
+will remember its most recent successful peer connections so if it
+is rebooted, it can quickly reestablish connections with its former peer
 network. If none of the former peers respond to its connection request,
 the node can use the seed nodes to bootstrap again.
 
@@ -399,14 +399,14 @@ $ bitcoin-cli getpeerinfo
 To override the automatic management of peers and to specify a list of
 IP addresses, users can provide the option +-connect=<IPAddress>+ and
 specify one or more IP addresses. If this option is used, the node will
-only connect to the selected IP addresses, instead of discovering and
+only connect to the selected IP addresses instead of discovering and
 maintaining the peer connections automatically.
 
 If there is no traffic on a connection, nodes will periodically send a
 message to maintain the connection. If a node has not communicated on a
 connection for too long, it is assumed to be disconnected
 and a new peer will be sought. Thus, the network dynamically adjusts to
-transient nodes and network problems, and can organically grow and
+transient nodes and network problems and can organically grow and
 shrink as needed without any ((("Bitcoin network", "nodes", "network discovery", startref="bitcoin-network-node-discovery")))((("nodes", "network discovery", startref="node-discovery")))((("network discovery", startref="network-discovery")))central control.
 
 === Full Nodes
@@ -449,7 +449,7 @@ node will have to download hundreds of thousands of blocks to
 synchronize with the network and reestablish the full blockchain.
 
 The
-process of syncing the blockchain starts with the +version+ message,
+process of syncing the blockchain starts with the +version+ message
 because that contains +BestHeight+, a node's current blockchain height
 (number of blocks). A node will see the +version+ messages from its
 peers, know how many blocks they each have, and be able to compare to
@@ -549,7 +549,7 @@ 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
 double-spending attack against lightweight clients. To defend against this, a lightweight
-client needs to connect randomly to several clients, to increase the
+client needs to connect randomly to several clients to increase the
 probability that it is in contact with at least one honest node. This
 need to randomly connect means that lightweight clients also are vulnerable to
 network partitioning attacks or Sybil attacks, where they are connected
@@ -603,7 +603,7 @@ A bloom filter((("Bitcoin network", "bloom filters", "operational overview", id=
 to describe a desired pattern without specifying it exactly. Bloom
 filters offer an efficient way to express a search pattern while
 protecting privacy. They are used by lightweight clients to ask their peers for
-transactions matching a specific pattern, without revealing exactly
+transactions matching a specific pattern without revealing exactly
 which addresses, keys, or transactions they are searching for.
 
 In our previous analogy, a tourist without a map is asking for
@@ -615,7 +615,7 @@ reveals slightly less about the desired destination than asking for "23
 Church St." Using this technique, a tourist could specify the desired
 address in more detail such as "ending in U-R-C-H" or less detail such as
 "ending in H." By varying the precision of the search, the tourist
-reveals more or less information, at the expense of getting more or less
+reveals more or less information at the expense of getting more or less
 specific results. If they ask for a less specific pattern, they get a lot
 more possible addresses and better privacy, but many of the results are
 irrelevant. If they ask for a very specific pattern, they get fewer
@@ -662,7 +662,7 @@ changed from +0+ to +1+.
 <<bloom2>> is an example of adding a pattern "A" to the simple bloom filter shown in <<bloom1>>.
 
 Adding a second pattern is as simple as repeating this process. The
-pattern is hashed by each hash function in turn and the result is
+pattern is hashed by each hash function in turn, and the result is
 recorded by setting the bits to +1+. Note that as a bloom filter is
 filled with more patterns, a hash function result might coincide with a
 bit that is already set to +1+, in which case the bit is not changed. In
@@ -726,16 +726,16 @@ transactions of interest to the lightweight client without revealing exactly whi
 addresses or keys it is interested in.
 
 A lightweight client will initialize a bloom filter
-as "empty"; in that state the bloom filter will not match any patterns.
+as "empty"; in that state, the bloom filter will not match any patterns.
 The lightweight client will then make a list of all the addresses, keys, and
 hashes that it is interested in. It will do this by extracting the
-public key hash and script hash and transaction IDs from any UTXO
+public key hash, script hash, and transaction IDs from any UTXO
 controlled by its wallet. The lightweight client then adds each of these to the
-bloom filter, so that the bloom filter will "match" if these patterns
+bloom filter so that the bloom filter will "match" if these patterns
 are present in a transaction, without revealing the patterns themselves.
 
 The lightweight client will then send a
-+filterload+ message to the peer, containing the bloom filter to use on
++filterload+ message to the peer containing the bloom filter to use on
 the connection. On the peer, bloom filters are checked against each
 incoming transaction. The full node checks several parts of the
 transaction against the bloom filter, looking for a match including:
@@ -826,11 +826,11 @@ weren't created by the client.  They can even download each matching
 block from a different peer, making it harder for full nodes to connect
 transactions belonging to a single client across multiple blocks.
 
-This idea for server-generated filters doesn't offer perfect privacy,
+This idea for server-generated filters doesn't offer perfect privacy;
 it still places some costs on full nodes (and it does require lightweight
-clients use more bandwidth for the block download), and the filters can
-only be used for confirmed transactions (not unconfirmed transactions),
-but it is much more private and reliable than BIP37 client-requested
+clients to use more bandwidth for the block download), and the filters can
+only be used for confirmed transactions (not unconfirmed transactions). However,
+it is much more private and reliable than BIP37 client-requested
 bloom filters.
 
 After the description of the original idea based on bloom filters,
@@ -930,7 +930,7 @@ differences:
 |===
 
 If we know that we might need to store large numbers (because large
-differences can happen, even if they are rare) but we'll most often need
+differences can happen, even if they are rare), but we'll most often need
 to store small numbers, we can encode each number using a system that
 uses less space for small numbers and extra space for large numbers.
 On average, that system will perform better than using the same amount
@@ -968,14 +968,14 @@ accurate filter.
 For both the primary and secondary goals to be met, a filter would need
 to reference two types of information:
 
-* The script for every output in every transaction in a block.
+* The script for every output in every transaction in a block
 
-* The outpoint for every input in every transaction in a block.
+* The outpoint for every input in every transaction in a block
 
 An early design for compact block filters included both of those pieces
-of information, but it was realized that there was a more efficient way
+of information, but it was realized there was a more efficient way
 to accomplish the primary goal if we sacrificed the secondary goal.  In
-the new design, a block filter would still references two types of
+the new design, a block filter would still reference two types of
 information, but they'd be more closely related:
 
 * As before, the script for every output in every transaction in a
@@ -1072,7 +1072,7 @@ finding the differences (deltas) between each entry.  That compact block
 filter is then distributed by peers to their clients (such as wallets).
 
 A client uses the deltas to reconstruct the original commitments.  The
-client such as a wallet also takes all the output scripts it is
+client, such as a wallet, also takes all the output scripts it is
 monitoring for and generates commitments in the same way as BIP158.  It
 checks whether any of its generated commitments match the commitments in
 the filter.
@@ -1085,7 +1085,7 @@ compact block filter contains the number 1234.  When a client sees that
 
 There's a 100% guarantee that an accurate filter containing 1234 will
 allow a client to learn about a block containing 123456, called a _true
-positive_.  However, there's also chance that the block might contain
+positive_.  However, there's also a chance that the block might contain
 123400, 123401, or almost a hundred other entries that are not what the
 client is looking for (in this example), ((("false positives")))called a _false positive_.
 
@@ -1141,7 +1141,7 @@ communications: _Tor transport_.
 Tor, which
 stands for _The Onion Routing network_, is a software project and
 network that offers encryption and encapsulation of data through
-randomized network paths that offer anonymity, untraceability and
+randomized network paths that offer anonymity, untraceability, and
 privacy.
 
 Bitcoin Core ((("Bitcoin Core", "Tor transport")))offers several configuration options that allow you to run
@@ -1192,7 +1192,7 @@ children). Any matching orphans are then validated. If valid, they are
 removed from the orphan pool and added to the mempool,
 completing the chain that started with the parent transaction. In light
 of the newly added transaction, which is no longer an orphan, the
-process is repeated recursively looking for any further descendants,
+process is repeated recursively looking for any further descendants
 until no more descendants are found. Through this process, the arrival
 of a parent transaction triggers a cascade reconstruction of an entire
 chain of interdependent transactions by reuniting the orphans with

ch11_blockchain.adoc

@@ -10,7 +10,7 @@ full nodes (and sometimes light clients) to validate.
 
 The blockchain data structure is
 an ordered, back-linked list of blocks of transactions.  The blockchain
-can be stored as a flat file, or in a simple database.
+can be stored as a flat file or in a simple database.
 Blocks are linked "back," each referring to the previous block in the
 chain. The blockchain is often visualized
 as a vertical stack, with blocks layered on top of each other and the
@@ -32,8 +32,8 @@ Although a block has just one parent, it can have ((("child blocks")))multiple
 children. Each of the children commits to the same parent block.
 Multiple children arise during a blockchain "fork," a temporary
 situation that can occur when different blocks are discovered almost
-simultaneously by different miners (see <<forks>>). Eventually, only one
-child block becomes part of the blockchain accepted by all full nodes and the "fork" is resolved.
+simultaneously by different miners (see <<forks>>). Eventually only one
+child block becomes part of the blockchain accepted by all full nodes, and the "fork" is resolved.
 
 The "previous block hash" field is inside the block header and thereby
 affects the _current_ block's hash.
@@ -396,7 +396,7 @@ H<sub>A</sub> = SHA256(SHA256(Transaction A))
 </pre>
 ++++
 
-Consecutive pairs of leaf nodes are then summarized in a parent node, by
+Consecutive pairs of leaf nodes are then summarized in a parent node by
 concatenating the two hashes and hashing them together. For example, to
 construct the parent node H~AB~, the two 32-byte hashes of the children
 are concatenated to create a 64-byte string. That string is then
@@ -445,12 +445,11 @@ duplicate txids, resulting in a vulnerability (CVE-2012-2459).
 
 The reason is that if the number of hashes in the list at a given level
 is odd, the last one is duplicated before computing the next level (which
-is unusual in Merkle trees). This results in certain sequences of
+is unusual in merkle trees). This results in certain sequences of
 transactions leading to the same merkle root. For example, the two
 trees in <<cve_tree>>:
 
 [[cve_tree]]
-[role="figuresmallerninety"]
 .Two Bitcoin-style merkle tree with the same root but a different number of leaves
 image::images/mbc3_1104.png["Two Bitcoin-style merkle trees with the same root but a different number of leaves"]
 
@@ -488,7 +487,7 @@ To prove that a specific transaction is
 included in a block, a node only needs to produce approximately +log~2~(N)+ 32-byte
 hashes, constituting ((("authentication path")))((("merkle path")))an _authentication path_ or _merkle path_
 connecting the specific transaction to the root of the tree. This is
-especially important as the number of transactions increases, because
+especially important as the number of transactions increases because
 the base-2 logarithm of the number of transactions increases much more
 slowly. This allows Bitcoin nodes to efficiently produce paths of 10 or
 12 hashes (320–384 bytes), which can provide proof of a single
@@ -542,7 +541,7 @@ The lightweight client can use this merkle path to connect the transaction to th
 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
+and block and between the block and blockchain, proves that the
 transaction is recorded in the blockchain. All in all, the lightweight client will
 have received less than a kilobyte of data for the block header and
 merkle path, an amount of data that is more than a thousand times less
@@ -643,7 +642,7 @@ used to test segregated witness features.
 Testnet doesn't just use the same data structures as Bitcoin, it also
 uses almost exactly the same proof-of-work (PoW) security mechanism as
 Bitcoin.  The notable differences for testnet are that its minimum
-difficulty is half that of Bitcoin and that it's allowed to include a
+difficulty is half that of Bitcoin and it's allowed to include a
 block at the minimum difficulty if that block's timestamp is more than
 20 minutes after the previous block.
 
@@ -746,10 +745,10 @@ $ bitcoin-cli -signet getblockchaininfo
 Regtest, ((("blockchain", "test blockchains", "regtest", id="blockchain-test-regtest")))((("test blockchains", "regtest", id="test-block-regtest")))((("regtest", id="regtest")))which stands for
 "Regression Testing," is a Bitcoin Core feature that allows you to
 create a local blockchain for testing purposes. Unlike signet and testnet3, which
-are a public and shared test blockchain, the regtest blockchains are
+are public and shared test blockchains, the regtest blockchains are
 intended to be run as closed systems for local testing. You launch a
 regtest blockchain from scratch. You may
-add other nodes to the network, or run it with a single node only to
+add other nodes to the network or run it with a single node only to
 test the Bitcoin Core software.
 
 To start ((("Bitcoin Core", "regtest")))Bitcoin Core in regtest mode, you use the +regtest+ flag:
@@ -807,7 +806,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 reward for the first 400 blocks (coinbase
+you will see that you earned a reward 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):
 
 ----
@@ -820,10 +819,10 @@ $ bitcoin-cli -regtest getbalance
 Bitcoin's ((("blockchain", "test blockchains", "development usage")))((("test blockchains", "development usage")))various
 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,
+blockchains whether you are developing for Bitcoin Core or another
+full-node consensus client (an application such as a wallet, exchange,
 ecommerce site; or even developing novel smart contracts and complex
-scripts.
+scripts).
 
 You can use the test blockchains to establish a development pipeline.
 Test your code locally on a regtest as you develop it. Once you are
@@ -837,6 +836,6 @@ into production.
 
 Now that we know what data the blockchain contains and how cryptographic
 commitments securely tie the various parts together, we will look at the
-special commitment that both provides computational security and
-ensures no block can be changed without invalidating all other blocks
+special commitment that both provide computational security and
+ensure no block can be changed without invalidating all other blocks
 built on top of it: Bitcoin's mining function.

ch12_mining.adoc

@@ -74,7 +74,7 @@ will have been issued. After 2140, no new bitcoin
 will be issued.
 
 Bitcoin miners ((("transaction fees")))also earn fees from transactions. Every transaction may
-include a transaction fee, in the form of a surplus of bitcoins between
+include a transaction fee in the form of a surplus of bitcoins between
 the transaction's inputs and outputs. The winning bitcoin miner gets to
 "keep the change" on the transactions included in the winning block.
 Today, the fees usually represent only a small percentage of a
@@ -168,7 +168,7 @@ 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
-deflation 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
@@ -213,7 +213,7 @@ providing a clearinghouse service, basically verifying and clearing all
 transactions. Bitcoin has no central authority, yet somehow every full
 node has a complete copy of a public blockchain that it can trust as the
 authoritative record. The blockchain is not created by a central
-authority, but is assembled independently by every node in the network.
+authority but is assembled independently by every node in the network.
 Somehow, every node in the network, acting on information transmitted
 across insecure network connections, can arrive at the same conclusion
 and assemble a copy of the same blockchain as everyone else. This
@@ -221,7 +221,7 @@ chapter examines the process by which the Bitcoin network achieves
 global consensus without central authority.
 
 One of Satoshi Nakamoto's inventions is the decentralized
-mechanism for _emergent consensus_. Emergent, because consensus is not
+mechanism for _emergent consensus_. Emergent because consensus is not
 achieved explicitly—there is no election or fixed moment when consensus
 occurs. Instead, consensus is an emergent artifact of the asynchronous
 interaction of thousands of independent nodes, all following simple
@@ -237,15 +237,15 @@ processes that occur independently on nodes across the network:
 
 - Independent aggregation of those transactions into new blocks by
   mining nodes, coupled with demonstrated computation through a
-  Proof-of-Work algorithm
+  proof-of-work algorithm
 
 - Independent verification of the new blocks by every node and assembly
   into a chain
 
 - Independent selection, by every node, of the chain with the most
-  cumulative computation demonstrated through Proof-of-Work
+  cumulative computation demonstrated through proof of work
 
-In the next few sections we will examine these processes and how they
+In the next few sections, we will examine these processes and how they
 interact to create the emergent property of network-wide consensus that
 allows any Bitcoin node to assemble its own copy of the authoritative,
 trusted, public, global ((("bitcoins", "mining", "decentralized consensus", startref="bitcoin-mining-consensus")))((("mining", "decentralized consensus", startref="mining-consensus")))((("decentralized consensus", startref="decentral-consensus")))((("emergent consensus", startref="emergent-consensus")))blockchain.
@@ -440,7 +440,7 @@ fees (+nFees+), and the sum is returned.
 If Jing's mining node writes the coinbase transaction, what stops Jing
 from "rewarding" himself 100 or 1,000 bitcoin? The answer is that an
 inflated reward would result in the block being deemed invalid by
-everyone else, wasting Jing's electricity used for Proof-of-Work. Jing
+everyone else, wasting Jing's electricity used for PoW. Jing
 only gets to spend the reward if the block is accepted by ((("rewards", startref="reward-coinbase")))((("transaction fees", "in coinbase transactions", secondary-sortas="coinbase transactions", startref="transaction-fee-coinbase")))everyone.
 ====
 
@@ -524,7 +524,7 @@ structure of the((("inputs", "coinbase versus regular transactions"))) coinbase
 <tr>
 <td><p>Variable</p></td>
 <td><p>Coinbase Data</p></td>
-<td><p>Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height</p></td>
+<td><p>Arbitrary data used for extra nonce and mining tags; in v2 blocks, must begin with block height</p></td>
 </tr>
 <tr>
 <td><p>4 bytes</p></td>
@@ -554,7 +554,7 @@ be used by miners in any way they want; it is arbitrary data.
 In the genesis block, for
 example, Satoshi Nakamoto added the text "The Times 03/Jan/2009
 Chancellor on brink of second bailout for banks" in the coinbase data,
-using it as a proof of the earliest date this block chould have been
+using it as a proof of the earliest date this block could have been
 created and to convey a message. Currently,
 miners often use the coinbase data to include extra nonce values and strings
 identifying the mining pool.
@@ -604,12 +604,12 @@ as listed in <<block_header_structure_ch10>>.
 <tr>
 <td><p>4 bytes</p></td>
 <td><p>Target</p></td>
-<td><p>The Proof-of-Work algorithm target for this block</p></td>
+<td><p>The proof-of-work algorithm target for this block</p></td>
 </tr>
 <tr>
 <td><p>4 bytes</p></td>
 <td><p>Nonce</p></td>
-<td><p>A counter used for the Proof-of-Work algorithm</p></td>
+<td><p>A counter used for the proof-of-work algorithm</p></td>
 </tr>
 </tbody>
 </table>
@@ -662,11 +662,11 @@ transactions into a single 32-byte value, which is the _witness root
 hash_.
 
 The witness root hash is added to an output of the coinbase transaction.
-This step may be skipped if none of the transactions in the blook are
+This step may be skipped if none of the transactions in the block are
 required to contain a witness structure.  Each transaction (including
 the coinbase transaction) is then listed using its transaction
 identifier (_txid_) and used to build a second merkle tree, the root of
-which becomes the merkle root to which the block header commits.
+which becomes the merkle root, to which the block header commits.
 
 Jing's mining node will then add a 4-byte timestamp, encoded as a Unix
 "epoch" timestamp, which is based on the number of seconds elapsed from
@@ -674,7 +674,7 @@ January 1, 1970, midnight UTC/GMT.
 
 Jing's node then fills in the nBits target, which must be set to a
 compact representation of the required
-Proof-of-Work to make this a valid block. The target is stored in the
+PoW to make this a valid block. The target is stored in the
 block as a "target bits" metric, which is a mantissa-exponent encoding
 of the target. The encoding has a 1-byte exponent, followed by a 3-byte
 mantissa (coefficient). In block 277,316, for example, the target bits
@@ -696,7 +696,7 @@ the header before a version is found that satisfies the((("bitcoins", "mining",
 Now
 that((("candidate blocks", "mining", id="candidate-mine")))((("blocks", "candidate blocks", "mining", id="block-candidate-mine")))((("mining", "candidate blocks", id="mining-candidate")))((("bitcoins", "mining", "candidate blocks", id="bitcoin-mining-candidate"))) a candidate block has been constructed by Jing's node, it is time
 for Jing's hardware mining rig to "mine" the block, to find a solution
-to the Proof-of-Work algorithm that makes the block valid. Throughout
+to the proof-of-work algorithm that makes the block valid. Throughout
 this book we have studied cryptographic hash functions as used in
 various aspects of the Bitcoin system. The hash function SHA256 is the
 function used in Bitcoin's mining process.
@@ -762,12 +762,12 @@ f75a100821c34c84395403afd1a8135f685ca69ccf4168e61a90e50f47552f61  -
 
 The phrase "Hello, World! 32" produces the following hash, which fits our criteria: 
 +09cb91f8250df04a3db8bd98f47c7cecb712c99835f4123e8ea51460ccbec314+. It took 32 attempts to find it. In terms of
-probabilities, if the output of the hash function is evenly distributed
+probabilities, if the output of the hash function is evenly distributed,
 we would expect to find a result with a 0 as the hexadecimal prefix once
 every 16 hashes (one out of 16 hexadecimal digits 0 through F). In
 numerical terms, that means finding a hash value that is less than
 +0x1000000000000000000000000000000000000000000000000000000000000000+. We
-call this threshold the _target_ and the goal is to find a hash that is
+call this threshold the _target_, and the goal is to find a hash that is
 numerically less than the target. If we decrease the target, the task of
 finding a hash that is less than the target becomes more and more
 difficult.
@@ -787,10 +787,10 @@ From the perspective of an observer who knows that the target of the
 dice game is 2, if someone has succeeded in casting a winning throw it
 can be assumed that they attempted, on average, 36 throws. In other
 words, one can estimate the amount of work it takes to succeed from the
-difficulty imposed by the target. When the algorithm is a based on a
+difficulty imposed by the target. When the algorithm is based on a
 deterministic function such as SHA256, the input itself constitutes
 _proof_ that a certain amount of _work_ was done to produce a result
-below the target. Hence, _Proof-of-Work_.
+below the target. Hence, _proof of work_.
 
 [TIP]
 ====
@@ -799,7 +799,7 @@ any possible outcome can be calculated in advance. Therefore, an outcome
 of specified difficulty constitutes proof of a specific amount of work.
 ====
 
-In <<sha256_example_generator_output2>>, the winning "nonce" is 32 and
+In <<sha256_example_generator_output2>>, the winning "nonce" is 32, and
 this result can be confirmed by anyone independently. Anyone can add the
 number 32 as a suffix to the phrase "Hello, world!" and compute
 the hash, verifying that it is less than the target:
@@ -811,7 +811,7 @@ $ echo "Hello, world! 32" | sha256sum
 
 Although it only takes one hash computation to verify, it took
 us 32 hash computations to find a nonce that worked. If we had a lower
-target (higher difficulty) it would take many more hash computations to
+target (higher difficulty), it would take many more hash computations to
 find a suitable nonce, but only one hash computation for anyone to
 verify. Furthermore, by knowing the target, anyone can estimate the
 difficulty using statistics and therefore know roughly how much work was needed
@@ -819,13 +819,13 @@ to find such a nonce.
 
 [TIP]
 ====
-The Proof-of-Work must produce a hash that is _less than_ the target. A
+The PoW must produce a hash that is _less than_ the target. A
 higher target means it is less difficult to find a hash that is below
 the target. A lower target means it is more difficult to find a hash
 below the target. The target and difficulty are inversely related.
 ====
 
-Bitcoin's Proof-of-Work is very similar to the challenge
+Bitcoin's PoW is very similar to the challenge
 shown in <<sha256_example_generator_output2>>. The miner constructs a
 candidate block filled with transactions. Next, the miner calculates the
 hash of this block's header and sees if it is smaller than the current
@@ -843,7 +843,7 @@ enough block((("bitcoins", "mining", "Proof-of-Work algorithm", startref="bitcoi
 
 Block headers ((("bitcoins", "mining", "target representation", id="bitcoin-mining-target")))((("mining", "target representation", id="mining-target")))((("targets", "representation of", id="target-represent")))((("Proof-of-Work algorithm", "target representation", id="proof-target")))contain the target in a notation called "target
 bits" or just "bits," which in block 277,316 has the value of
-+0x1903a30c+. This notation expresses the Proof-of-Work target as a
++0x1903a30c+. This notation expresses the proof-of-work target as a
 coefficient/exponent format, with the first two hexadecimal digits for
 the exponent and the next six hex digits as the coefficient. In this
 block, therefore, the exponent is +0x19+ and the coefficient is
@@ -886,7 +886,7 @@ switching back to hexadecimal:
 ++++
 
 This means that a valid block for height 277,316 is one that has a block
-header hash that is less than the target. In binary that number must
+header hash less than the target. In binary that number must
 have more than 60 leading bits set to zero. With this level of
 difficulty, a single miner processing 1 trillion hashes per second (1
 terahash per second or 1 TH/sec) would only find a solution once every
@@ -897,7 +897,7 @@ terahash per second or 1 TH/sec) would only find a solution once every
 
 As we saw, ((("bitcoins", "mining", "adjusting difficulty", id="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", id="mining-difficulty")))((("targets", "adjusting difficulty", id="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", id="proof-difficulty")))((("difficulty", "adjusting", id="difficulty-adjust")))the target determines the difficulty and
 therefore affects how long it takes to find a solution to the
-Proof-of-Work algorithm. This leads to the obvious questions: Why is the
+proof-of-work algorithm. This leads to the obvious questions: Why is the
 difficulty adjustable, who adjusts it, and how?
 
 Bitcoin's blocks are generated every 10 minutes, on average. This is
@@ -908,14 +908,14 @@ it is expected that computer power will continue to increase at a rapid
 pace. Furthermore, the number of participants in mining and the
 computers they use will also constantly change. To keep the block
 generation time at 10 minutes, the difficulty of mining must be adjusted
-to account for these changes. In fact, the Proof-of-Work target is a
+to account for these changes. In fact, the proof-of-work target is a
 dynamic parameter that is periodically adjusted to meet a 10-minute
 block interval goal. In simple terms, the target is set so that the
 current mining power will result in a 10-minute block interval.
 
 How, then, is such an adjustment made in a completely decentralized
 network? Retargeting occurs automatically and on every node
-independently. Every 2,016 blocks, all nodes retarget the Proof-of-Work.
+independently. Every 2,016 blocks, all nodes retarget the PoW.
 The ratio between the actual time span and desired time span of 10
 minutes per block is calculated and a
 proportionate adjustment (up or down) is made to the target. In simple
@@ -940,7 +940,7 @@ resulting in a retargeting bias toward higher difficulty by 0.05%.
 <<retarget_code>> shows the code used in the Bitcoin Core client.
 
 [[retarget_code]]
-.Retargeting the Proof-of-Work&#x2014;[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
+.Retargeting the proof of work&#x2014;[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
 ====
 [source,cpp]
 ----
@@ -997,7 +997,7 @@ electricity. High-performance mining systems are about as efficient as
 possible with the current generation of silicon fabrication, converting
 electricity into hashing computation at the highest rate possible. The
 primary influence on the mining market is the price of one kilowatt-hour
-of electricity in bitcoin, because that determines the profitability of
+of electricity in bitcoin because that determines the profitability of
 mining and therefore the incentives to enter or exit the ((("bitcoins", "mining", "adjusting difficulty", startref="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", startref="mining-difficulty")))((("targets", "adjusting difficulty", startref="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", startref="proof-difficulty")))((("difficulty", "adjusting", startref="difficulty-adjust")))mining
 market.
 
@@ -1101,7 +1101,7 @@ The independent validation also ensures that only blocks that follow the
 consensus rules are incorporated in the blockchain, thus earning
 their miners the reward. Blocks that violate the rules are rejected
 and not only lose their miners the reward, but also waste the effort expended to find
-a Proof-of-Work solution, thus incurring upon those miners all of the costs of creating a
+a proof-of-work solution, thus incurring upon those miners all of the costs of creating a
 block but giving them none of the rewards.
 
 When a node receives a new block, it will validate the block by checking
@@ -1109,20 +1109,20 @@ it against a long list of criteria that must all be met; otherwise, the
 block is rejected. These criteria can be seen in the Bitcoin Core client
 in the functions +CheckBlock+ and +CheckBlockHeader+ and include:
 
-- The block data structure is syntactically valid
+- The block data structure is syntactically valid.
 
 - The block header hash is less than the target (enforces the
-  Proof-of-Work)
+  proof of work).
 
 - The block timestamp is between the MTP and two
-  hours in the future (allowing for time errors)
+  hours in the future (allowing for time errors).
 
-- The block weight is within acceptable limits
+- The block weight is within acceptable limits.
 
-- The first transaction (and only the first) is a coinbase transaction
+- The first transaction (and only the first) is a coinbase transaction.
 
 - All transactions within the block are valid using the transaction
-  checklist discussed in <<tx_verification>>
+  checklist discussed in <<tx_verification>>.
 
 The independent validation of each new block by every node on the
 network ensures that the miners cannot cheat. In previous sections we
@@ -1135,7 +1135,7 @@ the entire block invalid, which would result in the block being rejected
 and, therefore, that transaction would never become part of the blockchain.
 The miners have to construct a block, based on the shared rules
 that all nodes follow, and mine it with a correct solution to the
-Proof-of-Work. To do so, they expend a lot of electricity in mining, and
+PoW. To do so, they expend a lot of electricity in mining, and
 if they cheat, all the electricity and effort is wasted. This is why
 independent validation is a key component of ((("bitcoins", "mining", "validating blocks", startref="bitcoin-mining-validate")))((("mining", "validating blocks", startref="mining-validate")))((("blocks", "validating", startref="block-validate")))((("validating", "blocks", startref="validate-block")))((("decentralized consensus", "validating blocks", startref="decentral-consensus-validate")))((("nodes", "validating blocks", startref="nodes-validate")))decentralized consensus.
 
@@ -1146,14 +1146,14 @@ independent validation is a key component of ((("bitcoins", "mining", "validatin
 
 The final ((("bitcoins", "mining", "assembling blockchain", id="bitcoin-mining-assemble")))((("mining", "assembling blockchain", id="mining-assemble")))((("blockchain", "assembling", id="blockchain-assemble")))((("decentralized consensus", "assembling blockchain", id="decentral-consensus-assemble")))part in Bitcoin's decentralized
 consensus mechanism is the assembly of blocks into chains and the
-selection of the chain with the most Proof-of-Work.
+selection of the chain with the most proof of work.
 
 A _best blockchain_ is whichever valid chain of blocks has
-the most cumulative Proof-of-Work associated with it.
+the most cumulative PoW associated with it.
 The
 best chain may also have branches with blocks that are "siblings" to
 the blocks on the best chain. These blocks are valid but not part of the
-best chain. They are kept for future reference, in case one of those
+best chain. They are kept for future reference in case one of those
 secondary chains later becomes primary.  When sibling blocks occur,
 they're usually the result of an
 almost simultaneous mining of different blocks at the same height.
@@ -1234,7 +1234,7 @@ deliver more mining power in a single box than the entire Bitcoin
 network in 2010.
 
 At the time of writing, it is believed that there are no more giant
-leaps left in Bitcoin mining equipment,
+leaps left in Bitcoin mining equipment
 because the industry has reached the forefront of((("Moore&#x27;s Law"))) Moore's Law, which
 stipulates that computing density will double approximately every 18
 months. Still, the mining power of the network continues to advance at
@@ -1268,7 +1268,7 @@ extra nonce space, allowing them to explore a much larger range of block
 header values to find valid blocks. The coinbase transaction is included
 in the merkle tree, which means that any change in the coinbase script
 causes the merkle root to change. Eight bytes of extra nonce, plus the 4
-bytes of "standard" nonce allow miners to explore a total 2^96^ (8
+bytes of "standard" nonce, allow miners to explore a total 2^96^ (8
 followed by 28 zeros) possibilities _per second_ without having to
 modify the timestamp.
 
@@ -1318,9 +1318,9 @@ server while mining, synchronizing their efforts with the other miners.
 Thus, the pool miners share the effort to mine a block and then share in
 the rewards.
 
-Successful blocks pay the reward to a pool Bitcoin address, rather than
+Successful blocks pay the reward to a pool Bitcoin address rather than to
 individual miners. The pool server will periodically make payments to
-the miners' Bitcoin addresses, once their share of the rewards has
+the miners' Bitcoin addresses once their share of the rewards has
 reached a certain threshold. Typically, the pool server charges a
 percentage fee of the rewards for providing the pool-mining service.
 
@@ -1340,14 +1340,14 @@ will be mining with a few tens of a kilowatt of electricity, others will
 be running a data center consuming megawatts of power. How does a
 mining pool measure the individual contributions, so as to fairly
 distribute the rewards, without the possibility of cheating? The answer
-is to use Bitcoin's Proof-of-Work algorithm to measure each pool miner's
+is to use Bitcoin's proof-of-work algorithm to measure each pool miner's
 contribution, but set at a lower difficulty so that even the smallest
 pool miners win a share frequently enough to make it worthwhile to
 contribute to the pool. By setting a lower difficulty for earning
 shares, the pool measures the amount of work done by each miner. Each
 time a pool miner finds a block header hash that is less than the pool
 target, they prove they have done the hashing work to find that result.
-That header ultimately commits to the coinbase transaction and so it can
+That header ultimately commits to the coinbase transaction and can
 be used to prove the miner used a coinbase transaction that would have
 paid the block reward to the pool.  Each pool miner is given a
 slightly different coinbase transaction template so each of them hashes
@@ -1503,7 +1503,7 @@ product without paying for it.
 Let's examine a practical example of a 51% attack. In the first chapter,
 we looked at a transaction between Alice and Bob. Bob, the seller, is
 willing to accept payment without waiting for
-confirmation (mining in a block), because the risk of a double-spend on
+confirmation (mining in a block) because the risk of a double-spend on
 a small item is low in comparison to the convenience of rapid
 customer service. This is similar to the practice of coffee shops that
 accept credit card payments without a signature for amounts below $25,
@@ -1531,7 +1531,7 @@ Mallory's transaction is included in a block. Paul directs the mining
 pool to remine the same block height as the block containing Mallory's
 transaction, replacing Mallory's payment to Carol with a transaction
 that double-spends the same input as Mallory's payment. The double-spend
-transaction consumes the same UTXO and pays it back to Mallory's wallet,
+transaction consumes the same UTXO and pays it back to Mallory's wallet
 instead of paying it to Carol, essentially allowing Mallory to keep the
 bitcoins. Paul then directs the mining pool to mine an additional block,
 so as to make the chain containing the double-spend transaction longer
@@ -1541,7 +1541,7 @@ the new (longer) chain, the double-spent transaction replaces the
 original payment to Carol. Carol is now missing the three paintings and
 also has no payment. Throughout all this activity, Paul's mining
 pool participants might remain blissfully unaware of the double-spend
-attempt, because they mine with automated miners and cannot monitor
+attempt because they mine with automated miners and cannot monitor
 every transaction or block.
 
 To protect against this
@@ -1572,9 +1572,9 @@ Despite its ((("majority attacks", startref="majority-attack")))((("51% attacks"
 of the hashing power. In fact, such an attack can be attempted with a
 smaller percentage of the hashing power. The 51% threshold is simply the
 level at which such an attack is almost guaranteed to succeed. A
-hashrate attack is essentially a tug-of-war for the next block and the
+hashrate attack is essentially a tug-of-war for the next block, and the
 "stronger" group is more likely to win. With less hashing power, the
-probability of success is reduced, because other miners control the
+probability of success is reduced because other miners control the
 generation of some blocks with their "honest" mining power. One way to
 look at it is that the more hashing power an attacker has, the longer
 the fork he can deliberately create, the more blocks in the recent past
@@ -1596,7 +1596,7 @@ Not all attackers will be motivated by profit, however. One potential
 attack scenario is where an attacker intends to disrupt the Bitcoin
 network without the possibility of profiting from such disruption. A
 malicious attack aimed at crippling Bitcoin would require enormous
-investment and covert planning, but could conceivably be launched by a
+investment and covert planning but could conceivably be launched by a
 well-funded, most likely state-sponsored, attacker. Alternatively, a
 well-funded attacker could attack Bitcoin by simultaneously
 amassing mining hardware, compromising pool operators, and attacking
@@ -1638,7 +1638,7 @@ after one or more blocks are mined.
 
 There is another scenario in which the network may diverge into
 following two chains: a change in the consensus rules. This type of fork
-is called a _hard fork_, because after the fork the network may not
+is called a _hard fork_, because after the fork, the network may not
 converge onto a single chain. Instead, the two chains can evolve
 independently. Hard forks occur when part of the network is operating
 under a different set of consensus rules than the rest of the network.
@@ -1676,7 +1676,7 @@ containing this transaction.
 Any node or miner that has not upgraded the software to validate foocoin
 is now unable to process block 7b. From their perspective,
 both the transaction that contained a foocoin and block 7b that
-contained that transaction are invalid, because they are evaluating them
+contained that transaction are invalid because they are evaluating them
 based upon the old consensus rules. These nodes will reject the
 transaction and the block and will not propagate them. Any miners that
 are using the old rules will not accept block 7b and will continue to
@@ -1810,7 +1810,7 @@ that do not have near-unanimous support are considered too contentious
 to attempt without risking a partition of the system.
 
 Already we have seen the emergence of new methodologies to address the
-risks of hard forks. In the next section, we will look at soft forks,
+risks of hard forks. In the next section, we will look at soft forks
 and the methods for signaling and activation of
 consensus modifications.
 
@@ -1872,7 +1872,7 @@ to increasing the future cost of code maintenance because of design
 trade-offs made in the past. Code complexity in turn increases the
 likelihood of bugs and security vulnerabilities.
 
-Validation relaxation:: Unmodified clients see transactions as valid,
+Validation relaxation:: Unmodified clients see transactions as valid
 without evaluating the modified consensus rules. In effect, the
 unmodified clients are not validating using the full range of consensus
 rules, as they are blind to the new rules. This applies to NOP-based
@@ -1919,7 +1919,7 @@ version to "2," instead of "1." This did not immediately make version
 invalid and all version "2" blocks would be required to contain the
 block height in the coinbase to be valid.
 
-BIP34 defined a two-step activation mechanism, based on a rolling
+BIP34 defined a two-step activation mechanism based on a rolling
 window of 1,000 blocks. A miner would signal their individual
 readiness for BIP34 by constructing blocks with "2" as the version
 number. Strictly speaking, these blocks did not yet have to comply with
@@ -1993,7 +1993,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 and after +TIMEOUT+, the bits can be "recycled" to propose
 new changes.
 
 [NOTE]
@@ -2014,7 +2014,7 @@ number.
 bit:: 0 through 28, the bit in the block version that miners use to
 signal approval for this proposal.
 
-starttime:: The time (based on median time past, or MTP) that signaling
+starttime:: The time (based on MTP) that signaling
 starts after which the bit's value is interpreted as signaling readiness
 for the proposal.
 
@@ -2030,7 +2030,7 @@ later.
 BIP9 offers a proposal state diagram to illustrate the various stages
 and transitions for a proposal, as shown in <<bip9states>>.
 
-Proposals start in the +DEFINED+ state, once their parameters are known
+Proposals start in the +DEFINED+ state once their parameters are known
 (defined) in the Bitcoin software. For blocks with MTP after the start
 time, the proposal state transitions to +STARTED+. If the voting
 threshold is exceeded within a retarget period and the timeout has not
@@ -2100,7 +2100,7 @@ Software was published that used BIP8 to attempt to activate the
 taproot proposal in 2021, and there was evidence that at least a
 small number of users ran that software.  Some of those users also claim
 that their willingness to use BIP8 to force miners to activate taproot
-was the reason it did eventually activate.  They claim that, if taproot
+was the reason it did eventually activate.  They claim that if taproot
 had not been activated quickly, other users would have also begun
 running BIP8.  Unfortunately, there's no way to prove what would have
 happened, and so we can't say for sure how much BIP8 contributed to the
@@ -2136,7 +2136,7 @@ future attempt to activate a ((("consensus rules", "soft forks", "speedy trial a
 
 === Consensus Software Development
 
-Consensus software((("consensus rules", "software development")))((("software development for consensus rules")))((("forks", "consensus rule software development"))) continues to evolve and there is much
+Consensus software((("consensus rules", "software development")))((("software development for consensus rules")))((("forks", "consensus rule software development"))) continues to evolve, and there is much
 discussion on the various mechanisms for changing the consensus rules.
 By its very nature, Bitcoin sets a very high bar on coordination and
 consensus for changes. As a decentralized system, it has no "authority"

ch13_security.adoc

@@ -36,7 +36,7 @@ payment is open-ended because it contains the user's private identifier
 to the identifier can "pull" funds and charge the owner again and again.
 Thus, the payment network has to be secured end-to-end with encryption
 and must ensure that no eavesdroppers or intermediaries can compromise
-the payment traffic, in transit or when it is stored (at rest). If a bad
+the payment traffic in transit or when it is stored (at rest). If a bad
 actor gains access to the system, he can compromise current transactions
 _and_ payment tokens that can be used to create new transactions. Worse,
 when customer data is compromised, the customers are exposed to identity
@@ -81,7 +81,7 @@ for their customers.
 
 Unless you are prepared to invest heavily in operational security,
 multiple layers of access control, and audits (as the traditional banks
-do) you should think very carefully before taking funds outside of
+do), you should think very carefully before taking funds outside of
 Bitcoin's decentralized security context. Even if you have the funds and
 discipline to implement a robust security model, such a design merely
 replicates the fragile model of traditional financial networks, plagued
@@ -262,7 +262,7 @@ Multisignature addresses secure funds by requiring more than one
 signature to make a payment. The signing keys should be stored in a
 number of different locations and under the control of different people.
 In a corporate environment, for example, the keys should be generated
-independently and held by several company executives, to ensure no
+independently and held by several company executives to ensure no
 single person can compromise the funds. Multisignature addresses can
 also offer redundancy, where a single person holds several keys that are
 stored in different locations.

ch14_applications.adoc

@@ -25,7 +25,7 @@ Immutability:: Once a transaction is recorded in the blockchain and
 sufficient work has been added with subsequent blocks, the transaction's
 data becomes practically immutable. Immutability is underwritten by energy, as
 rewriting the blockchain requires the expenditure of energy to produce
-Proof-of-Work. The energy required and therefore the degree of
+PoW. The energy required and therefore the degree of
 immutability increases with the amount of work committed on top of the
 block containing a transaction.
 
@@ -65,9 +65,9 @@ without invalidating the signature, thus invalidating the transaction
 itself.
 
 Transaction Atomicity:: Bitcoin transactions are atomic. They are either
-valid and confirmed (mined) or not. Partial transactions cannot be mined
+valid and confirmed (mined) or not. Partial transactions cannot be mined,
 and there is no interim state for a transaction. At any point in time a
-transaction is either mined, or not.
+transaction is either mined or not.
 
 Discrete (Indivisible) Units of Value:: Transaction outputs are discrete
 and indivisible units of value. They can either be spent or unspent, in
@@ -98,10 +98,10 @@ Recording External State:: A transaction can commit to a data value, via
 +OP_RETURN+ or pay to contract, representing a state transition in an external state
 machine.
 
-Predictable Issuance:: Less than 21 million bitcoin will be issued, at a
+Predictable Issuance:: Less than 21 million bitcoin will be issued at a
 predictable rate.
 
-The list of building blocks is not complete and more are added with each
+The list of building blocks is not complete, and more are added with each
 new feature introduced ((("Bitcoin", "as application platform", "primitives, list of", secondary-sortas="application platform", startref="bitcoin-app-platform-primitive")))((("application platform, Bitcoin as", "primitives, list of", startref="app-platform-primitive")))((("primitives", startref="primitive-list")))((("building blocks", startref="build-block")))into Bitcoin.
 
 === Applications from Building Blocks
@@ -115,7 +115,7 @@ Proof-of-Existence (Digital Notary):: Immutability + Timestamp + Durability.
 A transaction on the blockchain can commit to a value,
 proving that a piece of data existed at the time
 it was recorded (Timestamp). The commitment cannot be modified ex-post-facto
-(Immutability) and the proof will be stored permanently (Durability).
+(Immutability), and the proof will be stored permanently (Durability).
 
 Kickstarter (Lighthouse):: Consistency + Atomicity + Integrity. If you
 sign one input and the output (Integrity) of a fundraiser transaction,
@@ -231,14 +231,14 @@ validation.  That brings ((("colored coins application", "P2C (pay to contract)"
 ==== Client-Side Validation
 
 Bob had ((("colored coins application", "client-side validation")))((("client-side validation")))((("validating", "with client-side validation", secondary-sortas="client-side validation")))some colored coins associated with a UTXO.  He spent that UTXO
-in a way that committed to a contract which indicated how the next
+in a way that committed to a contract that indicated how the next
 receiver (or receivers) of the colored coins will prove their ownership
 over the coins in order to further spend them.
 
 In practice, Bob's P2C contract likely simply committed to one or more
 unique identifiers for the UTXOs that will be used as single-use seals
 for deciding when the colored coins are next spent.  For example, Bob's
-contract may have indicated that the UTXO that Alice received to her P2C
+contract may have indicated that the UTXO Alice received to her P2C
 tweaked public key now controls half of his colored coins, with the
 other half of his colored coins now being assigned to a different UTXO
 that may have nothing to do with the transaction between Alice and Bob.
@@ -341,7 +341,7 @@ Translated forwarding::
 Native forwarding is conceptually simpler but essentially requires a
 separate Lightning Network for every asset.  Translated forwarding
 allows building on the economies of scale of the Bitcoin Lightning
-Network but it may be vulnerable to a problem called((("free American call option"))) the _free American
+Network, 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
 siphon money from the hop next to them.  Although there's no known
@@ -361,7 +361,7 @@ working on BIPs that may be available after this book goes((("Bitcoin", "as appl
 === Payment Channels and State Channels
 
 _Payment channels_ are ((("Bitcoin", "as application platform", "payment channels", secondary-sortas="application platform", id="bitcoin-app-platform-payment")))((("application platform, Bitcoin as", "payment channels", id="app-platform-payment")))((("payment channels", id="payment-channel")))a trustless mechanism for exchanging Bitcoin
-transactions between two parties, outside of the Bitcoin blockchain.
+transactions between two parties outside of the Bitcoin blockchain.
 These transactions, which would be valid if settled on the Bitcoin
 blockchain, are held offchain instead, waiting for
 eventual batch settlement. Because the transactions are not settled,
@@ -370,15 +370,15 @@ extremely high transaction throughput, low latency, and
 fine granularity.
 
 Actually, the term _channel_ is a metaphor. State channels are virtual
-constructs represented by the exchange of state between two parties,
-outside of the blockchain. There are no "channels" per se and the
+constructs represented by the exchange of state between two parties
+outside of the blockchain. There are no "channels" per se, and the
 underlying data transport mechanism is not the channel. We use the term
-channel to represent the relationship and shared state between two
-parties, outside of the blockchain.
+_channel_ to represent the relationship and shared state between two
+parties outside of the blockchain.
 
 To further explain this
 concept, think of a TCP stream. From the perspective of higher-level
-protocols it is a "socket" connecting two applications across the
+protocols, it is a "socket" connecting two applications across the
 internet. But if you look at the network traffic, a TCP stream is just a
 virtual channel over IP packets. Each endpoint of the TCP stream
 sequences and assembles IP packets to create the illusion of a stream of
@@ -404,7 +404,7 @@ the state being altered is the balance of a virtual currency.
 ==== State Channels—Basic Concepts and Terminology
 
 A state channel((("payment channels", "state channels", id="payment-channel-state")))((("state channels", id="state-channel-terminology")))((("transactions", "state channels", id="transaction-state"))) is
-established between two parties, through a transaction that locks a
+established between two parties through a transaction that locks a
 shared state on the blockchain. This is called ((("funding transactions")))the _funding transaction_.
 This single transaction must be transmitted to
 the network and mined to establish the channel. In the example of a
@@ -438,7 +438,7 @@ In the entire lifetime of the channel, only two transactions need to be
 submitted for mining on the blockchain: the funding and settlement
 transactions. In between these two states, the two parties can exchange
 any number of commitment transactions that are never seen by anyone
-else, nor submitted to the blockchain.
+else or submitted to the blockchain.
 
 <<payment_channel>> illustrates a payment channel between Bob and Alice,
 showing the funding, commitment, and settlement ((("payment channels", "state channels", startref="payment-channel-state")))((("state channels", startref="state-channel-terminology")))((("transactions", "state channels", startref="transaction-state")))transactions.
@@ -453,7 +453,7 @@ To
 explain ((("payment channels", "example of", id="payment-channel-example")))state channels, we start with a very simple example. We
 demonstrate a one-way channel, meaning that value is flowing in one
 direction only. We will also start with the naive assumption that no one
-is trying to cheat, to keep things simple. Once we have the basic
+is trying to cheat to keep things simple. Once we have the basic
 channel idea explained, we will then look at what it takes to make it
 trustless so that neither party _can_ cheat, even if they are trying to.
 
@@ -525,7 +525,7 @@ second commitment transaction, together with another second of video.
 
 In this way, Emma's software continues to send commitment transactions
 to Fabian's server in exchange for streaming video. The balance of the
-channel gradually accumulates in favor of Fabian, as Emma consumes more
+channel gradually accumulates in favor of Fabian as Emma consumes more
 seconds of video. Let's say Emma watches 600 seconds (10 minutes) of
 video, creating and signing 600 commitment transactions. The last
 commitment transaction (#600) will have two outputs, splitting the
@@ -564,7 +564,7 @@ to fix those:
 
 - While the channel is running, Emma can take any of the commitment
   transactions Fabian has countersigned and transmit one to the
-  blockchain. Why pay for 600 seconds of video, if she can transmit
+  blockchain. Why pay for 600 seconds of video if she can transmit
   commitment transaction #1 and only pay for 1 second of video? The
   channel fails because Emma can cheat by broadcasting a prior
   commitment that is in her favor.
@@ -578,11 +578,11 @@ transaction at the same time. She signs the funding transaction but
 doesn't transmit it to anyone. Emma transmits only the refund
 transaction to Fabian and obtains his signature.
 
-The refund transaction acts as the first commitment transaction and its
+The refund transaction acts as the first commitment transaction, and its
 timelock establishes the upper bound for the channel's life. In this
 case, Emma could set the lock time to 30 days or 4,320 blocks into the
 future. All subsequent commitment transactions must have a shorter
-timelock, so that they can be redeemed before the refund transaction.
+timelock so they can be redeemed before the refund transaction.
 
 Now that Emma has a fully signed refund transaction, she can confidently
 transmit the signed funding transaction knowing that she can eventually,
@@ -591,7 +591,7 @@ disappears.
 
 Every commitment transaction the parties exchange during the life of the
 channel will be timelocked into the future. But the delay will be
-slightly shorter for each commitment so the most recent commitment can
+slightly shorter for each commitment, so the most recent commitment can
 be redeemed before the prior commitment it invalidates. Because of the
 lock time, neither party can successfully propagate any of the
 commitment transactions until their timelock expires. If all goes well,
@@ -637,14 +637,14 @@ construct more flexible, useful, and sophisticated state channels.
 
 Timelocks are not the only way to invalidate prior commitment
 transactions. In the next sections we will see how a revocation key can
-be used to achieve the same result. Timelocks are effective but they
+be used to achieve the same result. Timelocks are effective, but they
 have two distinct disadvantages. By establishing a maximum timelock when
 the channel is first opened, they limit the lifetime of the channel.
 Worse, they force channel implementations to strike a balance between
 allowing long-lived channels and forcing one of the participants to wait
 a very long time for a refund in case of premature closure. For example,
-if you allow the channel to remain open for 30 days, by setting the
-refund timelock to 30 days, if one of the parties disappears immediately
+if you allow the channel to remain open for 30 days by setting the
+refund timelock to 30 days, if one of the parties disappears immediately,
 the other party must wait 30 days for a refund. The more distant the
 endpoint, the more distant the refund.
 
@@ -689,10 +689,10 @@ transaction and builds a settlement transaction that is identical in
 every way except that it omits the timelock. Both parties can sign this
 settlement transaction knowing there is no way to cheat and get a more
 favorable balance. By cooperatively signing and transmitting the
-settlement transaction they can close the channel and redeem their
+settlement transaction, they can close the channel and redeem their
 balance immediately. Worst case, one of the parties can be petty, refuse
 to cooperate, and force the other party to do a unilateral close with
-the most recent commitment transaction. But if they do that, they have
+the most recent commitment transaction. If they do that, they have
 to wait for their funds ((("payment channels", "trustless channels", startref="payment-channel-trustless")))((("trustless channels", startref="trustless-channel")))((("timelocks", "trustless channels", startref="timelock-trustless")))((("commitment transactions", "trustless channels", startref="commit-trustless")))too.
 
 ==== Asymmetric Revocable Commitments
@@ -825,7 +825,7 @@ redemption script for that output allows one party to redeem it after
 key, penalizing transmission of a revoked commitment.
 
 So when Hitesh creates a commitment transaction for Irene to sign, he
-makes the second output payable to himself after 1,000 blocks, or to the
+makes the second output payable to himself after 1,000 blocks or to the
 revocation public key (of which he only knows half the secret). Hitesh
 constructs this transaction. He will only reveal his half of the
 revocation secret to Irene when he is ready to move to a new channel
@@ -850,8 +850,8 @@ ENDIF
 CHECKSIG
 ----
 
-Irene can confidently sign this transaction, since if transmitted it
-will immediately pay her what she is owed. Hitesh holds the transaction,
+Irene can confidently sign this transaction since if transmitted, it
+will immediately pay her what she is owed. Hitesh holds the transaction
 but knows that if he transmits it in a unilateral channel closing, he
 will have to wait 1,000 blocks to get paid.
 
@@ -872,7 +872,7 @@ The revocation protocol is bilateral, meaning that in each round, as the
 channel state is advanced, the two parties exchange new commitments,
 exchange revocation secrets for the previous commitments, and sign each
 other's new commitment transactions. After they accept a new state, they
-make the prior state impossible to use, by giving each other the
+make the prior state impossible to use by giving each other the
 necessary revocation secrets to punish any cheating.
 
 Let's look at an example of how it works. One of Irene's customers wants
@@ -883,7 +883,7 @@ reflect the new balance. They will commit to a new state (state number
 bitcoins to Irene. To advance the state of the channel, they will each
 create new commitment transactions reflecting the new channel balance.
 
-As before, these commitment transactions are asymmetric so that the
+As before, these commitment transactions are asymmetric so the
 commitment transaction each party holds forces them to wait if they
 redeem it. Crucially, before signing new commitment transactions, they
 must first exchange revocation keys to invalidate any outdated commitments.
@@ -891,7 +891,7 @@ In this particular case, Hitesh's interests are aligned with the real
 state of the channel and therefore he has no reason to broadcast a prior
 state. However, for Irene, state number 1 leaves her with a higher
 balance than state 2. When Irene gives Hitesh the revocation key for her
-prior commitment transaction (state number 1) she is effectively
+prior commitment transaction (state number 1), she is effectively
 revoking her ability to profit from regressing the channel to a prior
 state because with the revocation key, Hitesh can redeem both outputs of
 the prior commitment transaction without delay. Meaning if Irene
@@ -919,7 +919,7 @@ channel.
 Payment channels ((("payment channels", "HTLC (Hash Time Lock Contract)", id="payment-channel-htlc")))((("HTLC (Hash Time Lock Contract)", id="htlc")))can be further
 extended with a special type of smart contract that allows the
 participants to commit funds to a redeemable secret, with an expiration
-time. This feature is called a _Hash Time Lock Contract_, or _HTLC_, and
+time. This feature is called a _hash time lock contract_, or _HTLC_, and
 is used in both bidirectional and routed payment channels.
 
 Let's first explain the "hash" part of the HTLC. To create an HTLC, the
@@ -957,8 +957,8 @@ ENDIF
 Anyone who knows the secret +R+, which when hashed equals to +H+, can
 redeem this output by exercising the first clause of the +IF+ flow.
 
-If the secret is not revealed and the HTLC claimed, after a certain
-number of blocks the payer can claim a refund using the second clause in
+If the secret is not revealed and the HTLC claimed after a certain
+number of blocks, the payer can claim a refund using the second clause in
 the +IF+ flow.
 
 This is a basic implementation of an HTLC. This type of HTLC can be
@@ -1008,7 +1008,7 @@ Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to
 Eric by a payment channel. Creating a payment channel requires a funding
 transaction, which must be committed to the Bitcoin blockchain. Alice
 does not want to open a new payment channel and commit more of her
-funds. Is there a way to pay Eric, indirectly?
+funds. Is there a way to pay Eric indirectly?
 
 <<ln_payment_process>> shows the step-by-step process of routing a
 payment from Alice to Eric, through a series of HTLC commitments on the
@@ -1113,17 +1113,17 @@ construct a _path_ through the network by connecting payment channels
 with sufficient capacity. Nodes advertise routing information, including
 what channels they have open, how much capacity each channel has, and
 what fees they charge to route payments. The routing information can be
-shared in a variety of ways and different pathfinding protocols have
+shared in a variety of ways, and different pathfinding protocols have
 emerged as Lightning Network technology has advanced.
 Current implementations of
 route discovery use a P2P model where nodes propagate channel
-announcements to their peers, in a "flooding" model, similar to how
+announcements to their peers in a "flooding" model, similar to how
 Bitcoin propagates transactions.
 
 In our previous example, Alice's node uses one of these route discovery
 mechanisms to find one or more paths connecting her node to Eric's node.
 Once Alice's node has constructed a path, she will initialize that path
-through the network, by propagating a series of encrypted and nested
+through the network by propagating a series of encrypted and nested
 instructions to connect each of the adjacent payment channels.
 
 Importantly, this path is only known to Alice's node. All other
@@ -1132,10 +1132,10 @@ Carol's perspective, this looks like a payment from Bob to Diana. Carol
 does not know that Bob is actually relaying a payment from Alice. She
 also doesn't know that Diana will be relaying a payment to Eric.
 
-This is a critical feature of the Lightning Network, because it ensures
+This is a critical feature of the Lightning Network because it ensures
 privacy of payments and makes it difficult to apply surveillance,
 censorship, or blacklists. But how does Alice establish this payment
-path, without revealing anything to the intermediary nodes?
+path without revealing anything to the intermediary nodes?
 
 The Lightning Network implements an onion-routed protocol based on a
 scheme called https://oreil.ly/fuCiK[Sphinx]. This routing protocol
@@ -1148,7 +1148,7 @@ through the Lightning Network such that:
 - Other than the previous and next hops, they cannot learn about any
   other nodes that are part of the path.
 
-- They cannot identify the length of the payment path, or their own
+- They cannot identify the length of the payment path or their own
   position in that path.
 
 - Each part of the path is encrypted in such a way that a network-level

copyright.html

@@ -3,7 +3,7 @@
 
 <p class="author">by <span class="firstname">Andreas </span> <span class="othername mi">M. </span> <span class="surname">Antonopoulos</span> and <span class="firstname">David </span> <span class="othername mi">A. </span> <span class="surname">Harding</span></p>
 
-<p class="copyright">Copyright © 2023 David Harding. All rights reserved.</p>
+<p class="copyright">Copyright © 2024 David Harding. All rights reserved.</p>
 
 <p class="printlocation">Printed in the United States of America.</p>
 
@@ -16,8 +16,8 @@
 	<li><span class="staffrole">Development Editor: </span>Angela Rufino</li>
 	<li><span class="staffrole">Production Editor:</span> Clare Laylock</li>
 	<li><span class="staffrole">Copyeditor:</span> Kim Cofer</li>
-	<li><span class="staffrole">Proofreader:</span></li>
-	<li><span class="staffrole">Indexer:</span></li>
+	<li><span class="staffrole">Proofreader:</span> Heather Walley</li>
+	<li><span class="staffrole">Indexer:</span> nSight, Inc.</li>
 	<li><span class="staffrole">Interior Designer:</span> David Futato</li>
 	<li><span class="staffrole">Cover Designer:</span> Randy Comer</li>
 	<li><span class="staffrole">Illustrator:</span> Kate Dullea</li>

meta/github_contrib.adoc

@@ -142,7 +142,7 @@
 <li>ratijas</li>
 <li>rating89us</li>
 <li>Raul Siles (raulsiles)</li>
-<li>Reproducibility Matters (TheCharlatan)</li>
+<li><p class="left-align">Reproducibility Matters <span class="keep-together">(TheCharlatan)</span></p></li>
 <li>Reuben Thomas (rrthomas)</li>
 <li>Robert Furse (Rfurse)</li>
 <li>Roberto Mannai (robermann)</li>

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 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
    pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#tx_fees">#tx_fees</a>].
 
 <<c_transactions>>::

preface.asciidoc

@@ -61,7 +61,7 @@ All the code snippets use real values and calculations where possible, so that y
 
 This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
 
-We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-491-95438-6.”
+We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_, 3rd ed., by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-098-15009-9.”
 
 Some editions of this book are offered under an open source license, such as https://oreil.ly/RzUHE[CC-BY-NC], in which case the terms of that license apply.
 
@@ -75,11 +75,11 @@ include::meta/third_edition_changes.asciidoc[]
 
 The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc.
 
-However, note that the private keys used to construct addresses are either printed in this book, or have been "burned." That means that if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here.
+However, note that the private keys used to construct addresses are either printed in this book or have been "burned." That means if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here.
 
 [WARNING]
 ====
-DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever.
+DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader or lost forever.
 ====
 
 === O'Reilly Online Learning
@@ -126,25 +126,25 @@ Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[].
 === Contacting the Authors
 
 You can contact Andreas M. Antonopoulos on his personal site:
-link:$$https://antonopoulos.com/$$[]
+[.keep-together]#link:$$https://antonopoulos.com$$[].#
 
 Follow Andreas on Facebook:
-link:$$https://facebook.com/AndreasMAntonopoulos$$[]
+link:$$https://facebook.com/AndreasMAntonopoulos$$[].
 
 Follow Andreas on Twitter:
-link:$$https://twitter.com/aantonop$$[]
+link:$$https://twitter.com/aantonop$$[].
 
 Follow Andreas on LinkedIn:
-link:$$https://linkedin.com/company/aantonop$$[]
+link:$$https://linkedin.com/company/aantonop$$[].
 
 Many thanks to all of Andreas's patrons who support his work through monthly donations. You can follow his Patreon page here:
-link:$$https://patreon.com/aantonop$$[]
+link:$$https://patreon.com/aantonop$$[].
 
-Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations are available on:
-link:$$https://bitcoinbook.info/$$[]
+Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations is available on:
+link:$$https://bitcoinbook.info$$[].
 
 You can contact David A. Harding on his personal site:
-link:$$https://dtrt.org/$$[]
+link:$$https://dtrt.org$$[].
 
 === Acknowledgments for the First and Second Editions
 
@@ -156,11 +156,11 @@ It is impossible to make a distinction between the Bitcoin technology and the Bi
 
 The journey to becoming an author starts long before the first book, of course. My first language (and schooling) was Greek, so I had to take a remedial English writing course in my first year of university. I owe thanks to Diana Kordas, my English writing teacher, who helped me build confidence and skills that year. Later, as a professional, I developed my technical writing skills on the topic of data centers, writing for _Network World_ magazine. I owe thanks to John Dix and John Gallant, who gave me my first writing job as a columnist at _Network World_ and to my editor Michael Cooney and my colleague Johna Till Johnson who edited my columns and made them fit for publication. Writing 500 words a week for four years gave me enough experience to eventually consider becoming an author.
 
-Thanks also to those who supported me when I submitted my book proposal to O'Reilly, by providing references and reviewing the proposal. Specifically, thanks to John Gallant, Gregory Ness, Richard Stiennon, Joel Snyder, Adam B. Levine, Sandra Gittlen, John Dix, Johna Till Johnson, Roger Ver, and Jon Matonis. Special thanks to Richard Kagan and Tymon Mattoszko, who reviewed early versions of the proposal and Matthew Taylor, who copyedited the proposal.
+Thanks also to those who supported me when I submitted my book proposal to O'Reilly by providing references and reviewing the proposal. Specifically, thanks to John Gallant, Gregory Ness, Richard Stiennon, Joel Snyder, Adam B. Levine, Sandra Gittlen, John Dix, Johna Till Johnson, Roger Ver, and Jon Matonis. Special thanks to Richard Kagan and Tymon Mattoszko, who reviewed early versions of the proposal and Matthew Taylor, who copyedited the proposal.
 
 Thanks to Cricket Liu, author of the O'Reilly title _DNS and BIND_, who introduced me to O'Reilly. Thanks also to Michael Loukides and Allyson MacDonald at O'Reilly, who worked for months to help make this book happen. Allyson was especially patient when deadlines were missed and deliverables delayed as life intervened in our planned schedule. For the second edition, I thank Timothy McGovern for guiding the process, Kim Cofer for patiently editing, and Rebecca Panzer for illustrating many new diagrams.
 
-The first few drafts of the first few chapters were the hardest, because Bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the Bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of Bitcoin through the stories of the people using Bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book, and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design.
+The first few drafts of the first few chapters were the hardest, because Bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the Bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of Bitcoin through the stories of the people using Bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design.
 
 During the development of the book, I made early drafts available on GitHub and invited public comments. More than a hundred comments, suggestions, corrections, and contributions were submitted in response. Those contributions are explicitly acknowledged, with my thanks, in <<github_contrib>>. Most of all, my sincere thanks to my volunteer GitHub editors Ming T. Nguyen (1st edition) and Will Binns (2nd edition), who worked tirelessly to curate, manage, and resolve pull requests, issue reports, and perform bug fixes on GitHub.