part 4 CE

appb_errata.adoc

@@ -1,12 +1,12 @@
 [appendix]
 == Errata to the Bitcoin Whitepaper
 
-A description of known problems in Satoshi Nakamoto’s paper, "Bitcoin:
+This appendix contains a description of known problems in Satoshi Nakamoto’s paper, "Bitcoin:
-A Peer-to-Peer Electronic Cash System", as well as notes on terminology
+A Peer-to-Peer Electronic Cash System," as well as notes on terminology
 changes and how Bitcoin's implementation differs from that described in
 the paper.
 
-This document was originally published by a co-author of this book in
+This document was originally published by a coauthor of this book in
 2016; it is reproduced here with updates.  The names of
 sections in this errata correspond to the names of the
 sections in Nakamoto's original paper.
@@ -19,12 +19,12 @@ 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
+the amount of PoW can vary between blocks, so it became important not to
 check for the "the longest chain" but rather "the chain demonstrating
-the most POW"; this is often shortened to "most-work chain".
+the most PoW"; this is often shortened to "most-work chain."
 +
 The
 https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420[change]
@@ -54,7 +54,7 @@ full validation nodes, which are programs that enforce all the rules of
 the system. Programs (and hardware) that extend the chain today are
 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 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.
 +
@@ -79,7 +79,7 @@ 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
 to say "as long as nodes cooperating to attack the network control less
-than about 30% of the network".
+than about 30% of the network."
 
 === Transactions
 
@@ -96,15 +96,15 @@ this system where digital signatures are not used directly but rather a
 matches a known public key can be used to enable a payment, the data
 that satisfies an 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
+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
-"a chain of encumbrances". Given that transactions often have more
+"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 graph
 (DAG).
 
-=== Proof-of-Work
+=== Proof of Work
 
 ____
 "we implement the proof-of-work by incrementing a nonce in the block
@@ -122,7 +122,7 @@ ____
 "Proof-of-work is essentially one-CPU-one-vote."
 ____
 
-* *Important note:* the vote here is not on the rules of the system but
+* *Important note:* The vote here is not on the rules of the system but
 merely on the ordering of the transactions in order to provide
 assurances that an "electronic coin" cannot be easily double spent.
 This is described in more detail in section 11 of the paper where it
@@ -147,7 +147,7 @@ used to calculate the average used for adjustment.
 Further, the average implemented in Bitcoin targets an average number of
 blocks per two weeks (not per hour as might be implied by the text).
 Other implemented rules may further slow adjustments, such as a rule
-that the adjustment can not increase block production speed by more than
+that the adjustment cannot increase block production speed by more than
 300% per period, nor slow it by more than 75%.
 
 === Reclaiming Disk Space
@@ -157,7 +157,7 @@ ____
 spent transactions before it can be discarded to save disk space"
 ____
 
-* *Possible post-publication discovery:* Although the Merkle Tree
+* *Possible post-publication discovery:* Although the merkle tree
 structure described in this section can prove a transaction was included
 in a particular block, there is currently no way in Bitcoin to prove
 that a transaction has not been spent except to process all subsequent
@@ -174,7 +174,7 @@ software to download the full block and alerted transactions to confirm
 the inconsistency."
 ____
 
-* *Important Note:* although software has been produced that implements
+* *Important Note:* Although software has been produced that implements
 some parts of this section and calls that Simplified Payment
 Verification (SPV), none of these programs currently accepts alerts from
 network nodes (full validation nodes) when invalid blocks have been
@@ -188,13 +188,13 @@ ____
 necessarily reveal that their inputs were owned by the same owner"
 ____
 
-* *Post-publication invention:* it isn't clear that different inputs
+* *Post-publication invention:* It isn't clear that different inputs
-in the same transaction have the same owner if if owners often mix their
+in the same transaction have the same owner if owners often mix their
 inputs with
 inputs belonging to other owners. For example, there’s no public
 difference between Alice and Bob each contributing one of their inputs
-towards paying Charlie and Dan than there is between just Alice
+toward paying Charlie and Dan than there is between just Alice
-contributing two of her inputs towards paying Charlie and Dan.
+contributing two of her inputs toward paying Charlie and Dan.
 +
 This technique is known today as
 https://en.bitcoin.it/wiki/CoinJoin[CoinJoin] and software implementing
@@ -210,12 +210,12 @@ lucky enough to get far enough ahead, then executing the transaction at
 that moment."
 ____
 
-* *Post-publication discovery:* nothing about the receiver generating a
+* *Post-publication discovery:* Nothing about the receiver generating a
 public key shortly before the spender signs a transaction prevents the
 spender from preparing a chain of blocks ahead of time. Early Bitcoin
 user Hal Finney discovered this attack and
 https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384[described
-it]: "Suppose the attacker is generating blocks occasionally. in each
+it]: "Suppose the attacker is generating blocks occasionally. In each
 block he generates, he includes a transfer from address A to address B,
 both of which he controls.
 +
@@ -230,11 +230,11 @@ the Finney Attack.
 
 '''''
 
-*Disclaimer:* the author of this document was not the first person to
+*Disclaimer:* The author of this document was not the first person to
 identify any of the problems described here—he has merely collected them
 into a single document.
 
-*License:* this errata document is released under the
+*License:* This errata document is released under the
 https://creativecommons.org/publicdomain/zero/1.0/[CC0] 1.0 Universal
 Public Domain Dedication
 

appc_bips.adoc

@@ -10,7 +10,7 @@ _Standard_ BIP:: Describes any change that affects most or all Bitcoin implement
 _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.
 
-BIPs are recorded in a versioned repository on GitHub: https://github.com/bitcoin/bips[https://github.com/bitcoin/bips].
+BIPs are recorded in a https://github.com/bitcoin/bips[versioned repository on GitHub].
 An MIT-licensed document from the open source Bitcoin Core project,
 reproduced here in edited form, describes which BIPs it implements, including listing
 the Pull Request (PR) and version of Bitcoin Core where support for each BIP was added or

author_bio.html

@@ -9,5 +9,5 @@
 
 <p>As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.</p>
 
-<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the co-author of the Bitcoin Optech weekly newsletter (2018-23), 21.co Bitcoin Computer tutorials (2015-17), and Bitcoin.org developer documentation (2014-15). He is also a Brink.dev grant committee member (2022-23) and former board member (2020-22).</p>
+<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the coauthor of the Bitcoin Optech weekly newsletter (2018–23), 21.co Bitcoin Computer tutorials (2015–17), and Bitcoin.org developer documentation (2014–15). He is also a Brink.dev grant committee member (2022–23) and former board member (2020–22).</p>
 </section>

ch06_transactions.adoc

@@ -281,7 +281,7 @@ pieces of information from it:
   assigned to that previous output.
 
 - For confirmed transactions, the height of the block which confirmed it
-  and the Median Time Past (MTP) for that block.  This is required for
+  and the median time past (MTP) for that block.  This is required for
   relative timelocks (described in <<relative_timelocks>>) and outputs
   of coinbase transactions (described in <<coinbase_transactions>>).
 

ch08_signatures.adoc

@@ -124,7 +124,7 @@ There are three +SIGHASH+ flags: +ALL+, +NONE+, and +SINGLE+, as shown
 in <<sighash_types_and_their>>.
 
 [[sighash_types_and_their]]
-.++SIGHASH++ types and their meanings
+.[.plain]#++SIGHASH++# types and their meanings
 [options="header"]
 |=======================
 |++SIGHASH++ flag| Value | Description
@@ -145,9 +145,9 @@ in <<sighash_types_with_modifiers>>.
 [options="header"]
 |=======================
 |++SIGHASH++ flag| Value | Description
-| ++ALL\++|++ANYONECANPAY++ | ++0x81++ | Signature applies to one input and all outputs
+| ++ALL\|ANYONECANPAY++ | ++0x81++ | Signature applies to one input and all outputs
-| ++NONE\++|++ANYONECANPAY++ | ++0x82++ | Signature applies to one input, none of the outputs
+| ++NONE\|ANYONECANPAY++ | ++0x82++ | Signature applies to one input, none of the outputs
-| ++SINGLE\++|++ANYONECANPAY++ | ++0x83++ | Signature applies to one input and the output with the same index number
+| ++SINGLE\|ANYONECANPAY++ | ++0x83++ | Signature applies to one input and the output with the same index number
 |=======================
 
 The way +SIGHASH+ flags are applied during signing and verification is
@@ -393,7 +393,7 @@ Bob waits to receive Alice's public nonce
   nonce +kG+.  This allows the impersonator to change parameters on both sides of
   the equation that Bob will use for verification, +sG == kG + exG+;
   specifically, they can change both +sG+ and +kG+.  Think about a
-  simplified form of that expression: x = y + a.  If you can change both
+  simplified form of that expression: +x = y + a+.  If you can change both
   +x+ and +y+, you can cancel out +a+ using +x' = (x - a) + a+.  Any
   value you choose for +x+ will now satisfy the equation.  For the
   actual equation the impersonator simply chooses a random number for +s+, generates
@@ -818,7 +818,7 @@ coordinate of the nonce _K_.
 From there, the algorithm calculates the _s_ value of the signature.  Like we did with schnorr signatures, operations involving
 integers are modulus p:
 
-_s_ = __k__^-1^ (__Hash__(__m__) + __x__ * __R__)
+_s_ = __k__^-1^ (__Hash__(__m__) + __x__ × __R__)
 
 where:
 

ch10_network.adoc

@@ -945,11 +945,11 @@ Our primary goal is to allow wallets to learn whether a block contains a
 transaction affecting that wallet.  For a wallet to be effective, it
 needs to learn two types of information:
 
-. When it has received money.  Specifically, when a transaction
+* When it has received money.  Specifically, when a transaction
    output contains a script that the wallet controls (such as by
    controlling the authorized private key).
 
-. When it has spent money.  Specifically, when a transaction input
+* When it has spent money.  Specifically, when a transaction input
    references a previous transaction output that the wallet controlled.
 
 A secondary goal during the design of compact block filters was to allow

ch12_mining.adoc

@@ -44,7 +44,7 @@ only valid if it spends the outputs of transactions that appeared
 earlier in the blockchain (whether they are earlier in the same block or
 in an earlier block), and only if no previous transaction spent any of
 those same outputs.  Within a single chain of blocks, the enforcement of
-topological ordering ensure no two valid transactions can spend the same
+topological ordering ensures no two valid transactions can spend the same
 output, eliminating the problem of _double spending_.
 
 In some protocols built on top of Bitcoin, the topological order of
@@ -56,7 +56,7 @@ return for the security provided by mining: new bitcoins created with each
 new block (called the _subsidy_), and transaction fees from all the transactions included in
 the block. To earn this reward, miners compete to satisfy a challenge
 based on a cryptographic hash algorithm. The
-solution to the problem, called the Proof-of-Work, is included in the
+solution to the problem, called the proof of work, is included in the
 new block and acts as proof that the miner expended significant
 computing effort. The competition to solve the Proof-of-Work algorithm
 to earn the reward and the right to record transactions on the
@@ -66,8 +66,8 @@ Bitcoin's money supply is created in a process that's similar to how
 a central bank issues new money by printing bank notes. The maximum
 amount of newly created bitcoin a miner can add to a block decreases
 approximately every four years (or precisely every 210,000 blocks). It
-started at 50 bitcoins per block in January of 2009 and halved to 25
+started at 50 bitcoins per block in January 2009 and halved to 25
-bitcoins per block in November of 2012. It halved again to 12.5 bitcoins
+bitcoins per block in November 2012. It halved again to 12.5 bitcoins
 in July 2016, and again to 6.25 in May 2020. Based on this formula, mining rewards decrease
 exponentially until approximately the year 2140, when all bitcoins
 will have been issued. After 2140, no new bitcoin
@@ -125,7 +125,7 @@ image::images/mbc3_1201.png["BitcoinMoneySupply"]
 
 [NOTE]
 ====
-The maximum number of bitcoinss mined is the _upper limit_ of possible
+The maximum number of bitcoins mined is the _upper limit_ of possible
 mining rewards for Bitcoin. In practice, a miner may intentionally mine
 a block taking less than the full reward. Such blocks have already been
 mined and more may be mined in the future, resulting in a lower total
@@ -271,7 +271,7 @@ criteria:
 
 - The transaction's syntax and data structure must be correct.
 
-- Neither lists of inputs or outputs are empty.
+- Neither lists of inputs nor outputs are empty.
 
 - The transaction weight is low enough to allow it to fit in a block.
 
@@ -326,7 +326,7 @@ follow Alice's transaction as it becomes part of this new block.
 
 Jing's mining node maintains a local copy of the blockchain. By the time
 Alice buys something, Jing's
-node is caught up with the chain of blocks with the most proof-of-work.
+node is caught up with the chain of blocks with the most proof of work.
 Jing's node is listening
 for transactions, trying to mine a new block and also listening for
 blocks discovered by other nodes. As Jing's node is mining, it receives
@@ -438,7 +438,7 @@ fees (+nFees+), and the sum is returned.
 [TIP]
 ====
 If Jing's mining node writes the coinbase transaction, what stops Jing
-from "rewarding" himself 100 or 1000 bitcoin? The answer is that an
+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
 only gets to spend the reward if the block is accepted by everyone.
@@ -467,7 +467,7 @@ structure of the coinbase transaction's input.
 | 4 bytes | Output Index | The index number of the UTXO to be spent, first one is 0
 | 1–9 bytes (compactSize) | Script Size | Script length in bytes, to follow
 | Variable | Input Script | A script that fulfills the conditions of the UTXO output script
-| 4 bytes | Sequence Number | Multipurpose field used for BIP68 time locks and transaction replacement signaling
+| 4 bytes | Sequence Number | Multipurpose field used for BIP68 timelocks and transaction replacement signaling
 |=======
 
 [[table_8-2]]
@@ -546,12 +546,12 @@ order, with BIP66 (strict DER) occuring before BIP65
 that order rather than sorted numerically.
 ====
 
-Today, VersionBits field has no meaning unless there's an attempt to
+Today, the VersionBits field has no meaning unless there's an attempt to
 upgrade the consensus protocol underway, in which case you will need to
 read its documentation to determine how it is using VersionBits.
 
 Next, the mining
-node needs to add the "Previous Block Hash" (also known as +prevhash+).
+node needs to add the "Previous Block Hash" (also known as [.keep-together]#+prevhash+).#
 That is the hash of the block header of the previous block
 received from the network, which Jing's node has accepted and
 selected as the _parent_ of his candidate block.
@@ -569,7 +569,7 @@ transaction is listed using its witness transaction identifier (_wtxid_)
 in topographical order, with 32 0x00 bytes standing in for the wtxid of
 the first transaction (the coinbase).  As we saw in the <<merkle_trees>>
 the last wtxid is hashed with itself if there are an odd number of wtxids,
-creating nodes that each containing the hash of one transaction. The
+creating nodes that each contain the hash of one transaction. The
 transaction hashes are then combined, in pairs, creating each level of
 the tree, until all the transactions are summarized into one node at the
 "root" of the tree. The root of the merkle tree summarizes all the
@@ -642,7 +642,7 @@ inputs.
 
 With SHA256, the output is always 256 bits long, regardless of the size
 of the input. For example, we will calculate the SHA256 hash of the
-phrase, "Hello, World!"
+phrase, "Hello, World!":
 
 ----
 $ echo "Hello, world!" | sha256sum
@@ -660,9 +660,10 @@ this case to vary the output of the SHA256 commitment to the phrase.
 
 To make a challenge out of this algorithm, let's set a target: find a
 phrase that produces a hexadecimal hash that starts with a zero.
-Fortunately, this isn't difficult:
+Fortunately, this isn't difficult, as shown in <<sha256_example_generator_output>>:
 
 [[sha256_example_generator_output]]
+.Simple proof-of-work implementation
 ----
 $ for nonce in $( seq 100 ) ; do echo "Hello, world! $nonce" | sha256sum ; done
 3194835d60e85bf7f728f3e3f4e4e1f5c752398cbcc5c45e048e4dbcae6be782  -
@@ -715,7 +716,7 @@ of specified difficulty constitutes proof of a specific amount of work.
 In <<sha256_example_generator_output>>, 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.
+the hash, verifying that it is less than the target:
 
 ----
 $ echo "Hello, world! 32" | sha256sum
@@ -829,7 +830,7 @@ 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.
-The ratio between the actual timespan and desired timespan of ten
+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
 terms: If the network is finding blocks faster than every 10 minutes,
@@ -890,7 +891,7 @@ required target adjustment is greater than a factor of four, it will be
 adjusted by a factor of 4 and not more. Any further adjustment will be
 accomplished in the next retargeting period because the imbalance will
 persist through the next 2,016 blocks. Therefore, large discrepancies
-between hashing power and difficulty might take several 2,016 block
+between hashing power and difficulty might take several 2,016-block
 cycles to balance out.
 
 Note that the target is independent of the number of transactions or the
@@ -917,7 +918,7 @@ market.
 [[mtp]]
 === Median Time Past (MTP)
 
-In bitcoin there is a subtle, but very
+In Bitcoin there is a subtle, but very
 significant, difference between wall time and consensus time. Bitcoin is
 a decentralized network, which means that each participant has his or
 her own perspective of time. Events on the network do not occur
@@ -946,24 +947,24 @@ _median time past_ (MTP).
 As part of the activation of BIP68 relative timelocks,
 there was also a change in the way "time" is calculated for timelocks
 (both absolute and relative) in transactions.   Previously, a miner
-could include any transaction in a block with a time lock equal to or
+could include any transaction in a block with a timelock equal to or
 below the time of the block.  That incentivized miners to use the latest
-possible time they thought was possible (close to two hours in the future)
+time they thought was possible (close to two hours in the future)
 so that more transactions would be eligible for their block.
 
 To remove the incentive to lie and strengthen the security of timelocks,
 BIP113 was proposed and activated at the same time as the BIPs for
 relative timelocks.
-The median time past became the consensus
+The MTP became the consensus
 time used for all timelock calculations. By taking the midpoint
 from approximately two hours in the past, the influence of any one
 block's timestamp is reduced. By incorporating 11 blocks, no single
 miner can influence the timestamps in order to gain fees from
 transactions with a timelock that hasn't yet matured.
 
-Median time past changes the implementation of time calculations for
+MTP changes the implementation of time calculations for
 lock time, +CLTV+, sequence, and +CSV+. The consensus time
-calculated by median time past is usually about one hour behind
+calculated by MTP is usually about one hour behind
 wall clock time. If you create timelock transactions, you should account
 for it when estimating the desired value to encode in lock time,
 sequence, +CLTV+, and +CSV+.
@@ -1027,7 +1028,7 @@ in the functions +CheckBlock+ and +CheckBlockHeader+ and include:
 - The block header hash is less than the target (enforces the
   Proof-of-Work)
 
-- The block timestamp is between the Median Time Past (MTP) and two
+- The block timestamp is between the MTP and two
   hours in the future (allowing for time errors)
 
 - The block weight is within acceptable limits
@@ -1085,7 +1086,7 @@ secondary chain and then compare the work of the secondary chain to the
 previous best chain. If the secondary chain is now the best chain, the
 node will accordingly _reorganize_ its view of confirmed transactions
 and available UTXOs.  If the node is a miner, it will now construct a
-candidate block extending this new, more-Proof of Work, chain.
+candidate block extending this new, more-proof-of-work, chain.
 
 By selecting the greatest-cumulative-work valid chain, all nodes
 eventually achieve network-wide consensus. Temporary discrepancies
@@ -1140,7 +1141,7 @@ The hashing power has increased exponentially every year of Bitcoin's
 existence. Some years the growth has reflected a complete change of
 technology, such as in 2010 and 2011 when many miners switched from
 using CPU mining to GPU mining and field programmable gate array (FPGA)
-mining. In 2013 the introduction of ASIC mining lead to another giant
+mining. In 2013 the introduction of ASIC mining led to another giant
 leap in mining power, by placing the double-SHA256 function directly on silicon
 chips specialized for the purpose of mining. The first such chips could
 deliver more mining power in a single box than the entire Bitcoin
@@ -1190,7 +1191,7 @@ header versionbits field for mining, as described in BIP320.  If each
 piece of mining equipment has its own coinbase transaction, this allows
 an individual piece of mining equipment to perform up to 281 TH/s by
 only making changes to the block header.  This keeps mining equipment
-and protocols simpler than incrementing the extranonce in the coinbase
+and protocols simpler than incrementing the extra nonce in the coinbase
 transaction every 4 billion hashes, which requires recalculating the
 entire left flank of the merkle tree up to the root.
 
@@ -1259,18 +1260,18 @@ 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, she proves she has done the hashing work to find that result.
+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
 be used to prove the miner used a coinbase transaction that would have
-paid the block reward to pool.  Each pool miner is given a
+paid the block reward to the pool.  Each pool miner is given a
 slightly different coinbase transaction template so each of them hashes
 different candidate block headers, preventing duplication of effort.
 
 The work to find shares contributes, in a
 statistically measurable way, to the overall effort to find a hash lower
-than the bitcoin network's target. Thousands of miners trying to find
+than the Bitcoin network's target. Thousands of miners trying to find
 low-value hashes will eventually find one low enough to satisfy the
-bitcoin network target.
+Bitcoin network target.
 
 Let's return to the analogy of a dice game. If the dice players are
 throwing dice with a goal of throwing less than four (the overall
@@ -1298,7 +1299,7 @@ whole pool wins.
 
 Most mining pools are "managed," meaning that
 there is a company or individual running a pool server. The owner of the
-pool server is called the _pool operator_, and he charges pool miners a
+pool server is called the _pool operator_, and they charge pool miners a
 percentage fee of the earnings.
 
 The pool server runs specialized software and a pool-mining protocol
@@ -1370,7 +1371,7 @@ control to a pool operator like managed pools.
 Even though P2Pool reduces the concentration of power by mining pool
 operators, it is conceivably vulnerable to 51% attacks against the share
 chain itself. A much broader adoption of P2Pool does not solve the 51%
-attack problem for bitcoin itself. Rather, P2Pool makes bitcoin more
+attack problem for Bitcoin itself. Rather, P2Pool makes Bitcoin more
 robust overall, as part of a diversified mining ecosystem.  As of this
 writing, P2Pool has fallen into disuse, but new protocols such as
 Stratum v2 can allow individual miners to choose the transactions they
@@ -1404,13 +1405,13 @@ miners can cause deliberate "forks" in the blockchain and double-spend
 transactions or execute denial-of-service attacks against specific
 transactions or addresses. A fork/double-spend attack is where the
 attacker causes previously confirmed blocks to be invalidated by forking
-below them and re-converging on an alternate chain. With sufficient
+below them and reconverging on an alternate chain. With sufficient
 power, an attacker can invalidate six or more blocks in a row, causing
 transactions that were considered immutable (six confirmations) to be
 invalidated. Note that a double-spend can only be done on the attacker's
 own transactions, for which the attacker can produce a valid signature.
 Double-spending one's own transactions can be profitable if invalidating
-a transaction allows the attacker can get an irreversible exchange payment or
+a transaction allows the attacker to get an irreversible exchange payment or
 product without paying for it.
 
 Let's examine a practical example of a 51% attack. In the first chapter,
@@ -1580,8 +1581,8 @@ image::images/mbc3_1202.png[A blockchain with forks]
 Later, however, at block height 6,
 a new implementation of the client is released with a change in the
 consensus rules. Starting on block height 7, miners running this new
-implementation will accept a new type of bitcoin, let's call
+implementation will accept a new type of bitcoin; let's call
-it a "foocoin". Immediately after, a
+it a "foocoin." Immediately after, a
 node running the new implementation creates a transaction that contains
 a foocoin and a miner with the updated software mines block 7b
 containing this transaction.
@@ -1661,7 +1662,7 @@ nodes that are sending them these invalid transactions and blocks. As a
 result, the network may partition into two: old nodes will only remain
 connected to old nodes and new nodes will only be connected to new
 nodes. A single block based on the new rules will ripple
-through the network and result in the partition into two networks.
+through the network and result in a partition into two networks.
 
 New miners may mine on top of the new block,
 while old miners will mine a separate chain based on the old rules. The
@@ -1687,7 +1688,7 @@ chain, the mining power has suddenly declined by 20% vis-a-vis the
 previous period. Blocks will be found on average every 12.5 minutes,
 representing the 20% decline in mining power available to extend this
 chain. This rate of block issuance will continue (barring any changes in
-hashing power) until 2016 blocks are mined, which will take
+hashing power) until 2,016 blocks are mined, which will take
 approximately 25,200 minutes (at 12.5 minutes per block), or 17.5 days.
 After 17.5 days, a retarget will occur and the difficulty will adjust
 (reduced by 20%) to produce 10-minute blocks again, based on the reduced
@@ -1696,7 +1697,7 @@ amount of hashing power in this chain.
 The minority chain, mining under the old rules with only 20% of the
 hashing power, will face a much more difficult task. On this chain,
 blocks will now be mined every 50 minutes on average. The difficulty
-will not be adjusted for 2016 blocks, which will take 100,800 minutes,
+will not be adjusted for 2,016 blocks, which will take 100,800 minutes,
 or approximately 10 weeks to mine. Assuming a fixed capacity per block,
 this will also result in a reduction of transaction capacity by a factor
 of 5, as there are fewer blocks per hour available to record
@@ -1749,15 +1750,13 @@ not vice versa. The new rules can only limit what is valid; otherwise,
 they will trigger a hard fork when rejected under the old rules.
 
 Soft forks can be implemented in a number of ways&#x2014;the term does
-not specify a particular method, rather a set of methods that all have
+not specify a particular method, but rather a set of methods that all have
 one thing in common: they don't require all nodes to upgrade or force
 nonupgraded nodes out of consensus.
 
-===== Soft forks redefining NOP opcodes
-
 Two soft forks have been
 implemented in Bitcoin, based on the re-interpretation of NOP opcodes.
-Bitcoin Script had ten opcodes reserved for future use, NOP1 through
+Bitcoin Script had 10 opcodes reserved for future use, NOP1 through
 NOP10. Under the consensus rules, the presence of these opcodes in a
 script is interpreted as a null-potent operator, meaning they have no
 effect. Execution continues after the NOP opcode as if it wasn't there.
@@ -1778,13 +1777,13 @@ relatively uncontroversial. The NOP opcodes were placed in Bitcoin
 Script with the explicit goal of allowing non-disruptive upgrades.
 
 However, many developers are concerned that other methods of soft fork
-upgrades make unacceptable tradeoffs. Common criticisms of soft fork
+upgrades make unacceptable trade-offs. Common criticisms of soft fork
 changes include:
 
 Technical debt:: Because soft forks are more technically complex than a
 hard fork upgrade, they introduce _technical debt_, a term that refers
 to increasing the future cost of code maintenance because of design
-tradeoffs made in the past. Code complexity in turn increases the
+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,
@@ -1835,20 +1834,20 @@ 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
-window of 1000 blocks. A miner would signal his or her individual
+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
 the new consensus rule of including the block-height in the coinbase
 transaction because the consensus rule had not yet been activated. The
 consensus rules activated in two steps:
 
-- If 75% (750 of the most recent 1000 blocks) are marked with version
+- If 75% (750 of the most recent 1,000 blocks) are marked with version
   "2," then version "2" blocks must contain block height in the coinbase
   transaction or they are rejected as invalid. Version "1" blocks are
   still accepted by the network and do not need to contain block-height.
   The old and new consensus rules coexist during this period.
 
-- When 95% (950 of the most recent 1000 blocks) are version "2," version
+- When 95% (950 of the most recent 1,000 blocks) are version "2," version
   "1" blocks are no longer considered valid. Version "2" blocks are
   valid only if they contain the block-height in the coinbase (as per
   the previous threshold). Thereafter, all blocks must comply with the
@@ -1860,11 +1859,11 @@ mechanism was used twice more to activate soft forks:
 
 - https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki[BIP66]
   Strict DER Encoding of Signatures was activated by BIP34 style
-  signaling with a block version "3".
+  signaling with a block version "3."
 
 - https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65]
   +CHECKLOCKTIMEVERIFY+ was activated by BIP34 style signaling with a
-  block version "4".
+  block version "4."
 
 After the activation of BIP65, the signaling and activation mechanism
 of BIP34 was retired and replaced with the BIP9 signaling mechanism
@@ -1894,7 +1893,7 @@ BIP9 was proposed to overcome these challenges and improve the rate and
 ease of implementing future changes.
 
 BIP9 interprets the block version as a bit field instead of an integer.
-Because the block version was originally used as an integer, versions 1
+Because the block version was originally used as an integer for versions 1
 through 4, only 29 bits remain available to be used as a bit field. This
 leaves 29 bits that can be used to independently and simultaneously
 signal readiness on 29 different proposals.
@@ -1929,7 +1928,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 median time past, or MTP) that signaling
 starts after which the bit's value is interpreted as signaling readiness
 for the proposal.
 
@@ -1937,16 +1936,16 @@ endtime:: The time (based on MTP) after which the change is considered
 rejected if it has not reached the activation threshold.
 
 Unlike BIP34, BIP9 counts activation signaling in whole intervals
-based on the difficulty retarget period of 2016 blocks. For every
+based on the difficulty retarget period of 2,016 blocks. For every
 retarget period, if the sum of blocks signaling for a proposal exceeds
-95% (1916 of 2016), the proposal will be activated one retarget period
+95% (1,916 of 2,016), the proposal will be activated one retarget period
 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
-(defined) in the bitcoin software. For blocks with MTP after the start
+(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
 been exceeded, the proposal state transitions to +LOCKED_IN+. One
@@ -1968,7 +1967,7 @@ The standard is defined in
 https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki[BIP9
 (Version bits with timeout and delay)].
 
-=== BIP8: mandatory lock-in with early activation
+=== BIP8: Mandatory Lock-in with Early Activation
 
 After BIP9 was successfully used for the CSV-related soft fork, the next
 implementation of a soft fork consensus change also attempted to use it
@@ -2021,7 +2020,7 @@ 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
 activation of taproot.
 
-=== Speedy trial: fail fast or succeed eventually
+=== Speedy Trial: Fail Fast or Succeed Eventually
 
 Although BIP9 by itself did not seem to result in the activation of
 segwit despite widespread support for the proposal, it was unclear to
@@ -2042,7 +2041,7 @@ six months later at a specified block height.  This mechanism was named
 _speedy trial_ by one of the people who helped promote it.
 
 Speedy trial activation was tried, miners quickly signaled their
-willingness to enforce the rules of taproot, and taproot was successful
+willingness to enforce the rules of taproot, and taproot was successfully
 activated about six months later.  To proponents of speedy trial, it was
 a clear success.  Others were still disappointed that BIP8 wasn't used.
 
@@ -2073,7 +2072,7 @@ reflective of this reality.
 
 It is important to recognize that there is no perfect
 solution for consensus development. Both hard forks and soft forks
-involve tradeoffs. For some types of changes, soft forks may be a better
+involve trade-offs. For some types of changes, soft forks may be a better
 choice; for others, hard forks may be a better choice. There is no
 perfect choice; both carry risks. The one constant characteristic of
 consensus software development is that change is difficult and consensus

ch13_security.adoc

@@ -16,7 +16,7 @@ not. A Bitcoin wallet, containing your keys, can be backed up like any
 file. It can be stored in multiple copies, even printed on paper for
 hard-copy backup. You can't "back up" cash, gold, or bank accounts.
 Bitcoin is different enough from anything that has come before that we
-need to think about securing your bitcoins in a novel way too.
+need to think about securing our bitcoins in a novel way too.
 
 === Security Principles
 
@@ -220,7 +220,7 @@ signing devices may become the predominant method of storing bitcoins.
 ==== Ensuring Your Access
 
 Although
-most users are rightly concerned about theft of thir bitcoins, there is an even
+most users are rightly concerned about theft of their bitcoins, there is an even
 bigger risk. Data files get lost all the time. If they contain Bitcoin keys,
 the loss is much more painful. In the effort to secure their Bitcoin
 wallets, users must be very careful not to go too far and end up losing
@@ -233,7 +233,7 @@ you secure your bitcoins too well you might not be able to find them again.
 
 [WARNING]
 ====
-To spend bitcoins, you may need to backup more than just your private
+To spend bitcoins, you may need to back up more than just your private
 keys or the BIP32 seed used to derive them.  This is especially the case
 when multisignatures or complex scripts are being used.  Most output
 scripts commit to the actual conditions that must be fulfilled to spend
@@ -282,10 +282,10 @@ existence of the bitcoin funds.
 
 If you have a lot of bitcoins, you should consider sharing access details
 with a trusted relative or lawyer. A more complex survivability scheme
-can be set up with multi-signature access and estate planning through a
+can be set up with multisignature access and estate planning through a
 lawyer specialized as a "digital asset executor."
 
-Bitcoin is a completely new, unprecedented, and complex technology. Over
+Bitcoin is a complex new technology that is still being explored by developers. Over
 time we will develop better security tools and practices that are easier
 to use by nonexperts. For now, Bitcoin users can use many of the tips
 discussed here to enjoy a secure and trouble-free Bitcoin experience.

ch14_applications.adoc

@@ -2,7 +2,7 @@
 == Second-Layer Applications
 
 Let's now build on our understanding of the primary Bitcoin system (the
-_first layer_) by looking at it as an
+_first layer_) by looking at it as a
 platform for other applications, or _second layers_. 
 In this chapter we will look at the features offered by Bitcoin
 as an application platform. We will consider the application
@@ -59,7 +59,7 @@ Nonexpiration:: A valid transaction does not expire. If it is valid
 today, it will be valid in the near future, as long as the inputs remain
 unspent and the consensus rules do not change.
 
-Integrity:: The outputs of Bitcoin transaction signed with +SIGHASH_ALL+ or parts of
+Integrity:: The outputs of a Bitcoin transaction signed with +SIGHASH_ALL+ or parts of
 a transaction signed by another +SIGHASH+ type cannot be modified
 without invalidating the signature, thus invalidating the transaction
 itself.
@@ -95,7 +95,7 @@ they are recorded. Once deeply recorded, the computation and energy
 required to change makes change practically infeasible.
 
 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
++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
@@ -139,7 +139,7 @@ Colored coins refers to a set of
 similar technologies that use Bitcoin transactions to record the
 creation, ownership, and transfer of extrinsic assets other than
 bitcoin. By "extrinsic" we mean assets that are not stored directly on
-the bitcoin blockchain, as opposed to bitcoin itself, which is an asset
+the Bitcoin blockchain, as opposed to bitcoin itself, which is an asset
 intrinsic to the blockchain.
 
 Colored coins are used to track digital
@@ -149,7 +149,7 @@ coins can represent intangible assets such as a stock certificate,
 license, virtual property (game items), or most any form of licensed
 intellectual property (trademarks, copyrights, etc.). Tangible asset
 colored coins can represent certificates of ownership of commodities
-(gold, silver, oil), land title, automobiles, boats, aircraft, etc.
+(gold, silver, oil), land titles, automobiles, boats, aircraft, etc.
 
 The term derives
 from the idea of "coloring" or marking a nominal amount of bitcoin, for
@@ -167,10 +167,10 @@ More recent implementations of colored coins use other mechanisms
 to attach metadata with a transaction, in conjunction with external
 data stores that associate the metadata to specific assets.  The three
 main mechanisms used as of this writing are single-use seals,
-pay-to-contract, and client-side validation.
+pay to contract, and client-side validation.
 
 [[single_use_seals]]
-==== Single-use seals
+==== Single-Use Seals
 
 Single-use seals originate in physical security.  Someone shipping an
 item through a third party needs a way to detect tampering, so they
@@ -181,7 +181,7 @@ opened in transit.
 
 In the context of colored coins, single-use seals refer to a data
 structure than can only be associated with another data structure once.
-In Bitcoin, this definition is fulfilled by Unspent Transaction Outputs
+In Bitcoin, this definition is fulfilled by unspent transaction outputs
 (UTXOs).  A UTXO can only be spent once within a valid blockchain, and
 the process of spending them associates them with the data in the
 spending transaction.
@@ -189,10 +189,10 @@ spending transaction.
 This provides part of the basis for the modern transfer for colored
 coins.  One or more colored coins are received to a UTXO.  When that
 UTXO is spent, the spending transaction must describe how the colored
-coins are to be spent.  That brings us to _Pay-to-Contract (P2C)_.
+coins are to be spent.  That brings us to _pay to contract (P2C)_.
 
 [[p2c_for_colored_coins]]
-==== Pay-to-Contract (P2C)
+==== Pay to Contract (P2C)
 
 We previously learned about P2C in <<pay_to_contract>>, where it became
 part of the basis for the taproot upgrade to Bitcoin's consensus rules.
@@ -228,7 +228,7 @@ Because full nodes don't (and can't) validate that the contract is
 followed correctly, we need to figure out who is responsible for
 validation.  That brings us to _client-side validation._
 
-==== Client-side validation
+==== Client-Side Validation
 
 Bob had some colored coins associated with a UTXO.  He spent that UTXO
 in a way that committed to a contract which indicated how the next
@@ -265,7 +265,7 @@ coins--for example, he'll never need to know what happened to the other
 half of Bob's coins, the ones that Bob didn't transfer to Alice.  This
 helps enhance the privacy of the colored coin protocol.
 
-Now that we've learned about single-use seals, pay-to-contract, and
+Now that we've learned about single-use seals, pay to contract, and
 client-side validation, we can look at the two main protocols that use
 them as of this writing, RGB and Taproot Assets.
 
@@ -278,17 +278,20 @@ payment channels (see <<state_channels>>), such as those used in
 Lightning Network.  That's accomplished at each layer of the RGB
 protocol:
 
-- Single-use seals: to create a payment channel, Bob assigns his colored
+Single-use seals:: 
+To create a payment channel, Bob assigns his colored
   coins to a UTXO that requires signatures from both him and Alice to
   spend.  Their mutual control over that UTXO serves as the single-use
   seal for future transfers.
 
-- Pay-to-Contract (P2C): Alice and Bob can now sign multiple versions of
+Pay to contract (P2C)::
+Alice and Bob can now sign multiple versions of
   a P2C contract.  The enforcement mechanism of the underlying payment
   channel ensures that both parties are incentivized to only publish the
   latest version of the contract onchain.
 
-- Client-side validation: to ensure that neither Alice nor Bob needs to
+Client-side validation::
+To ensure that neither Alice nor Bob needs to
   trust each other, they each check all previous transfers of the
   colored coins back to their creation to ensure all contract rules were
   followed correctly.
@@ -308,7 +311,7 @@ enabling MAST functionality (see <<mast>>).  The claimed advantage of
 Taproot Assets over RGB is that its similarity to the widely used
 taproot protocol makes it simpler for wallets and other software to
 implement.  One downside is that it may not be as flexible as the RGB
-protocol, especially when it comes to implementing non-asset features
+protocol, especially when it comes to implementing nonasset features
 such as identity tokens.
 
 [NOTE]
@@ -320,9 +323,9 @@ by Bitcoin is bitcoin.
 ====
 
 Even more than RGB, Taproot Assets has been designed to be compatible
-with Lightning Network.  One challenge with forwarding non-bitcoin assets
+with Lightning Network.  One challenge with forwarding nonbitcoin assets
 over Lightning Network is that there are two ways to accomplish the
-sending, each with a different set of tradeoffs:
+sending, each with a different set of trade-offs:
 
 Native forwarding::
   Every hop in the path between the spender and the receiver must know
@@ -472,7 +475,7 @@ image::images/mbc3_1402.png["Emma purchases streaming video from Fabian with a p
 
 In this example, Fabian and Emma are using special software that handles
 both the payment channel and the video streaming. Emma is running the
-software in her browser, Fabian is running it on a server. The software
+software in her browser; Fabian is running it on a server. The software
 includes basic Bitcoin wallet functionality and can create and sign
 Bitcoin transactions. Both the concept and the term "payment channel"
 are completely hidden from the users. What they see is video that is
@@ -567,7 +570,7 @@ to fix those:
   commitment that is in her favor.
 
 Both of these problems can be solved with timelocks&#x2014;let's look at
-how we could use transaction-level time locks.
+how we could use transaction-level timelocks.
 
 Emma cannot risk funding a 2-of-2 multisig unless she has a guaranteed
 refund. To solve this problem, Emma constructs the funding and refund
@@ -577,7 +580,7 @@ transaction to Fabian and obtains his signature.
 
 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 4320 blocks into the
+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.
 
@@ -598,8 +601,8 @@ commitment transaction. If not, the most recent commitment transaction
 can be propagated to settle the account and invalidate all prior
 commitment transactions.
 
-For example, if commitment transaction #1 is timelocked to 4320 blocks
+For example, if commitment transaction #1 is timelocked to 4,320 blocks
-in the future, then commitment transaction #2 is timelocked to 4319
+in the future, then commitment transaction #2 is timelocked to 4,319
 blocks in the future. Commitment transaction #600 can be spent 600
 blocks before commitment transaction #1 becomes valid.
 
@@ -648,8 +651,8 @@ endpoint, the more distant the refund.
 The second problem is that since each subsequent commitment transaction
 must decrement the timelock, there is an explicit limit on the number of
 commitment transactions that can be exchanged between the parties. For
-example, a 30-day channel, setting a timelock of 4320 blocks into the
+example, a 30-day channel, setting a timelock of 4,320 blocks into the
-future, can only accommodate 4320 intermediate commitment transactions
+future, can only accommodate 4,320 intermediate commitment transactions
 before it must be closed. There is a danger in setting the timelock
 commitment transaction interval at 1 block. By setting the timelock
 interval between commitment transactions to 1 block, a developer is
@@ -657,7 +660,7 @@ creating a very high burden for the channel participants who have to be
 vigilant, remain online and watching, and be ready to transmit the right
 commitment transaction at any time.
 
-In the above example of a single-direction channel, it's easy to
+In the preceding example of a single-direction channel, it's easy to
 eliminate the per-commitment timelock.  After Emma receives the
 signature on the timelocked refund transaction from Fabian, no timelocks
 are placed on the commitment transactions.  Instead, Emma sends her
@@ -700,7 +703,7 @@ key characteristic of Bitcoin is that once a transaction is valid, it
 remains valid and does not expire. The only way to cancel a transaction
 is to get a conflicting transaction confirmed.
 That's why we used timelocks in the simple payment channel
-example above to ensure that more recent commitments could be spent
+example to ensure that more recent commitments could be spent
 before older commitments were valid. However, sequencing commitments in
 time creates a number of constraints that make payment channels
 difficult to use.
@@ -748,7 +751,7 @@ transactions that are _asymmetric_.
 
 Hitesh has a commitment transaction with two outputs. The first output
 pays Irene the 5 bitcoins she is owed _immediately_. The second output
-pays Hitesh the 5 bitcoins he is owed, but only after a timelock of 1000
+pays Hitesh the 5 bitcoins he is owed, but only after a timelock of 1,000
 blocks. The transaction outputs look like this:
 
 ----
@@ -767,7 +770,7 @@ Output 1 <5 bitcoins>:
 Irene has a different commitment transaction with two outputs. The first
 output pays Hitesh the 5 bitcoins he is owed immediately. The second
 output pays Irene the 5 bitcoins she is owed but only after a timelock of
-1000 blocks. The commitment transaction Irene holds (signed by Hitesh)
+1,000 blocks. The commitment transaction Irene holds (signed by Hitesh)
 looks like this:
 
 ----
@@ -787,7 +790,7 @@ This way, each party has a commitment transaction, spending the 2-of-2
 funding output. This input is signed by the _other_ party. At any time
 the party holding the transaction can also sign (completing the 2-of-2)
 and broadcast. However, if they broadcast the commitment transaction, it
-pays the other party immediately whereas they have to wait for a
+pays the other party immediately, whereas they have to wait for a
 timelock to expire. By imposing a delay on the redemption of one of the
 outputs, we put each party at a slight disadvantage when they choose to
 unilaterally broadcast a commitment transaction. But a time delay alone
@@ -818,11 +821,11 @@ transaction is ever broadcast.
 
 Each of the commitment transactions has a "delayed" output. The
 redemption script for that output allows one party to redeem it after
-1000 blocks, _or_ the other party to redeem it if they have a revocation
+1,000 blocks, _or_ the other party to redeem it if they have a revocation
 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 1000 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,7 +853,7 @@ CHECKSIG
 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 1000 blocks to get paid.
+will have to wait 1,000 blocks to get paid.
 
 After the channel is advanced to the next state, Hitesh has to _revoke_
 this commitment transaction before Irene will agree to sign any further
@@ -861,9 +864,9 @@ commitment with confidence. She knows that if Hitesh tries to cheat by
 publishing the prior commitment, she can use the revocation key to
 redeem Hitesh's delayed output. _If Hitesh cheats, Irene gets BOTH
 outputs_. Meanwhile, Hitesh only has half the revocation secret for that
-revocation public key and can't redeem the output until 1000 blocks.
+revocation public key and can't redeem the output until 1,000 blocks.
 Irene will be able to redeem the output and punish Hitesh before the
-1000 blocks have elapsed.
+1,000 blocks have elapsed.
 
 The revocation protocol is bilateral, meaning that in each round, as the
 channel state is advanced, the two parties exchange new commitments,
@@ -898,7 +901,7 @@ the outputs.
 Importantly, the revocation doesn't happen automatically. While Hitesh
 has the ability to punish Irene for cheating, he has to watch the
 blockchain diligently for signs of cheating. If he sees a prior
-commitment transaction broadcast, he has 1000 blocks to take action and
+commitment transaction broadcast, he has 1,000 blocks to take action and
 use the revocation key to thwart Irene's cheating and punish her by
 taking the entire balance, all 10 bitcoins.
 
@@ -908,7 +911,7 @@ innovation in this technology.  With this construct, the channel can
 remain open indefinitely and can have billions of intermediate
 commitment transactions. In implementations of Lightning
 Network, the commitment state is identified by a 48-bit index, allowing
-more than 281 trillion (2.8 x 10^14^) state transitions in any single
+more than 281 trillion (2.8 × 10^14^) state transitions in any single
 channel.
 
 ==== Hash Time Lock Contracts (HTLC)
@@ -934,7 +937,7 @@ preimage is just the data that is used as input to a hash function.
 
 The second part of an HTLC is the "time lock" component. If the secret
 is not revealed, the payer of the HTLC can get a "refund" after some
-time. This is achieved with an absolute time lock using
+time. This is achieved with an absolute timelock using
 +CHECKLOCKTIMEVERIFY+.
 
 The script implementing an HTLC might look like this:
@@ -995,7 +998,7 @@ capacity of 4 bitcoins in each channel.
 
 <<lightning_network_fig>> shows five participants in a Lightning
 Network, connected by bidirectional payment channels that can be linked
-to make a payment from Alice to Eric (<<lightning_network>>).
+to make a payment from Alice to Eric (see <<lightning_network>>).
 
 [[lightning_network_fig]]
 .A series of bidirectional payment channels linked to form a Lightning Network that can route a payment from Alice to Eric
@@ -1035,7 +1038,7 @@ bitcoins (see <<ln_payment_process>> step 2). The extra 0.003 will be
 used to compensate the intermediate nodes for their participation in
 this payment route. Alice offers this HTLC to Bob, deducting 1.003
 bitcoins from her channel balance with Bob and committing it to the HTLC.
-The HTLC has the following meaning: _"Alice is committing 1.003 of her
+The HTLC has the following meaning: _"Alice is committing 1.003 bitcoins of her
 channel balance to be paid to Bob if Bob knows the secret, or refunded
 back to Alice's balance if 10 blocks elapse."_ The channel balance
 between Alice and Bob is now expressed by commitment transactions with
@@ -1044,7 +1047,7 @@ three outputs: 2 bitcoins balance to Bob, 0.997 bitcoins balance to Alice,
 the amount committed to the HTLC.
 
 Bob now has a commitment that if he is able to get the secret +R+ within
-the next 10 blocks, he can claim the 1.003 locked by Alice. With this
+the next 10 blocks, he can claim the 1.003 bitcoins locked by Alice. With this
 commitment in hand, Bob's node constructs an HTLC on his payment channel
 with Carol. Bob's HTLC commits 1.002 bitcoins to hash +H+ for 9 blocks,
 which Carol can redeem if she has secret +R+ (see <<ln_payment_process>>
@@ -1231,7 +1234,7 @@ applications expand the scope of Bitcoin beyond payments.
 
 Now that you have reached the end of this book, what will you do with
 the knowledge you have gained?  Millions of people, perhaps billions,
-know the name "Bitcoin", but only a small percentage of them know as
+know the name "Bitcoin," but only a small percentage of them know as
 much about how Bitcoin works as you now do.  That knowledge is precious.
 Even more precious are the people, such as yourself, who are so
 interested in Bitcoin that you are willing to read several hundred pages

copyright.html

@@ -27,18 +27,18 @@
 <ul class="printings">
 	<li><span class="printedition">December 2014:</span> First Edition</li>
 	<li><span class="printedition">June 2017:</span> Second Edition</li>
-	<li><span class="printedition">December 2023:</span> Third Edition</li>
+	<li><span class="printedition">November 2023:</span> Third Edition</li>
 </ul>
 <!--Add additional revdate spans below as needed.-->
 
 <div>
-<h1 class="revisions">Revision History for the First Edition</h1>
+<h1 class="revisions">Revision History for the Third Edition</h1>
 
 <!--ul class="releases">
 	<li><span class="revdate">2023-02-22:</span> First Release</li>
 </ul-->
 <ul class="releases">
-	<li><span class="revdate">2023-11-03:</span> First Edition</li>
+	<li><span class="revdate">2023-11-03:</span> First Release</li>
 </ul>
 </div>
 

theme/pdf/pdf.css

@@ -12,6 +12,13 @@ pre[data-type="programlisting"] {
   text-align: left;
 }
 
+
+/* roman (reverse emphasis) on varlist terms*/
+.plain {
+  font-style: normal;
+}
+
+
 /*hack to align sidebars to top of page*/
 .less_space {margin-top: 0 !important;}