qc1 and cleanup

appa_whitepaper.adoc

@@ -37,7 +37,7 @@ The ((("timestamp servers")))solution we propose begins with a timestamp server.
 image::images/mbc3_aain02.png["timestamp server"]
 
 ==== Proof-of-Work
-To ((("Proof-of-Work algorithm", "in Bitcoin whitepaper", secondary-sortas="Bitcoin whitepaper")))implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.  For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.
+To ((("proof-of-work algorithm", "in Bitcoin whitepaper", secondary-sortas="Bitcoin whitepaper")))implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.  For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.
 
 image::images/mbc3_aain03.png["pow"]
 

appb_errata.adoc

@@ -107,7 +107,7 @@ chain-like; it’s more accurately described as a directed acyclic ((("transacti
 === Proof of Work
 
 ____
-"we((("Proof-of-Work algorithm", "errata in Bitcoin whitepaper", id="proof-errata"))) implement the proof-of-work by incrementing a nonce in the block
+"...we((("proof-of-work algorithm", "errata in Bitcoin whitepaper", id="proof-errata"))) implement the proof-of-work by incrementing a nonce in the block
 until a value is found that gives the block’s hash the required zero
 bits."
 ____
@@ -135,7 +135,7 @@ transaction as payment, and honest nodes will never accept a block
 containing them."
 
 ____
-"proof-of-work difficulty is determined by a moving average targeting an
+"...proof-of-work difficulty is determined by a moving average targeting an
 average number of blocks per hour."
 ____
 
@@ -148,13 +148,13 @@ 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 cannot increase block production speed by more than
-300% per period, nor slow it by more ((("Proof-of-Work algorithm", "errata in Bitcoin whitepaper", startref="proof-errata")))than 75%.
+300% per period, nor slow it by more ((("proof-of-work algorithm", "errata in Bitcoin whitepaper", startref="proof-errata")))than 75%.
 
 === Reclaiming Disk Space
 
 ____
 "Once the ((("disk space, reclaiming")))((("reclaiming disk space")))((("blocks", "reclaiming disk space")))latest transaction in a coin is buried under enough blocks, the
-spent transactions before it can be discarded to save disk space"
+spent transactions before it can be discarded to save disk space."
 ____
 
 * *Possible post-publication discovery:* Although the merkle tree

appc_bips.adoc

@@ -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).

author_bio.html

@@ -1,13 +1,13 @@
 <section class="abouttheauthor" data-type="colophon" xmlns="http://www.w3.org/1999/xhtml">
 <h1>About the Authors</h1>
 
-<p><strong>Andreas M. Antonopoulos</strong> is a noted technologist and serial entrepreneur who has become one of the most well-known and well-respected figures in bitcoin. As an engaging public speaker, teacher, and writer, Andreas makes complex subjects accessible and easy to understand. As an advisor, he helps startups recognize, evaluate, and navigate security and business risks.</p>
+<p><strong>Andreas M. Antonopoulos</strong> is a noted technologist and serial entrepreneur who has become one of the most well-known and well-respected figures in Bitcoin. As an engaging public speaker, teacher, and writer, Andreas makes complex subjects accessible and easy to understand. As an advisor, he helps startups recognize, evaluate, and navigate security and business risks.</p>
 
 <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>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>As a bitcoin entrepreneur, Andreas has founded a number of Bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.</p>
 
 <p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the coauthor of the Bitcoin Optech weekly newsletter (2018–23), 21.co Bitcoin Computer tutorials (2015–17), and Bitcoin.org developer documentation (2014–15). He is also a Brink.dev grant committee member (2022–23) and former board member (2020–22).</p>
 </section>

ch01_intro.adoc

@@ -116,7 +116,7 @@ through a central clearinghouse.
 
 The Bitcoin network started in 2009, based on a reference implementation
 published by Nakamoto and since revised by many other programmers. The
-number and power of machines running the((("Proof-of-Work algorithm", seealso="mining"))) Proof-of-Work algorithm
+number and power of machines running the((("proof-of-work algorithm", seealso="mining"))) proof-of-work algorithm
 (mining) that provides security and resilience for Bitcoin have
 increased exponentially, and their combined computational power now
 exceeds the combined number of computing operations of the

ch02_overview.adoc

@@ -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
@@ -501,7 +501,7 @@ valid block something that requires an incredible amount of work to
 create but only a trivial amount of work to verify.  The simple
 verification process is able to probabalistically prove the work was
 done, so the data necessary to generate that proof--in this case, the
-block--is called ((("Proof-of-Work algorithm")))proof of work (PoW).
+block--is called ((("proof-of-work algorithm")))proof of work (PoW).
 
 Transactions are added to the new block, prioritized by the highest fee rate
 transactions first and a few other criteria. Each miner starts the

ch03_bitcoin-core.adoc

@@ -70,7 +70,7 @@ If you're a
 developer, you will want to set up a development environment with all
 the tools, libraries, and support software for writing Bitcoin
 applications. In this highly technical chapter, we'll walk through that
-process step-by-step. If the material becomes too dense (and you're not
+process step by step. If the material becomes too dense (and you're not
 actually setting up a development environment) feel free to skip to the
 next chapter, which is less technical.
 
@@ -928,7 +928,7 @@ f6cd83c3ca
   "difficulty": 157416.4018436489,
   "chainwork": "[...]00000000000000000000000000000000000000541788211ac227bc",
   "nTx": 13,
-  "previousblockhash": "[...]0b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
+  "previousblockhash": "[...]60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
   "nextblockhash": "[...]00129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66",
   "strippedsize": 4179,
   "size": 4179,

ch04_keys.adoc

@@ -328,7 +328,7 @@ 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
 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
-direction, from _k_ to _K_. That's why a Bitcoin public key can be
+direction, from _k_ to _K_. That's why a Bitcoin public key (_K_) can be
 shared with anyone and does not reveal the user's private key (_k_).
 
 [TIP]
@@ -1327,7 +1327,7 @@ 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:
 
 ----
@@ -1528,9 +1528,9 @@ 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
 used to produce compressed public keys. Private keys are not themselves
-compressed and cannot be compressed. The term "compressed private key"
+compressed and cannot be compressed. The term _compressed private key_
 really means "private key from which only compressed public keys should
-be derived," whereas "uncompressed private key" really means "private
+be derived," whereas _uncompressed private key_ really means "private
 key from which only uncompressed public keys should be derived." You
 should only refer to the export format as "WIF-compressed" or "WIF" and
 not refer to the private key itself as "compressed" to avoid further

ch05_wallets.adoc

@@ -125,8 +125,8 @@ subtraction, and multiplication operations used in regular
 arithmetic.  In other words, it's possible to add or subtract from a
 public key, or to multiply it.  Consider the operation we used in
 <<public_key_derivation>> for
-generating a public key (K) from a private key (k) using the generator
+generating a public key (_K_) from a private key (_k_) using the generator
-point (G):
+point (_G_):
 
 ----
 K = k * G
@@ -150,8 +150,8 @@ true) if the two sides aren't equivalent.
 
 An interesting consequence of this is that adding `123` to the public
 key can be done using entirely public information.  For example, Alice
-generates public key K and gives it to Bob.  Bob doesn't know the
+generates public key _K_ and gives it to Bob.  Bob doesn't know the
-private key, but he does know the global constant G, so he can add any
+private key, but he does know the global constant _G_, so he can add any
 value to the public key to produce a derived public child key.  If he
 then tells Alice the value he added to the public key, she can add the
 same value to the private key, producing a derived private child key
@@ -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 they can brute force the other half.  We
+bits), it's not plausible that 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
@@ -1474,7 +1474,7 @@ 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++'++.
+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

ch06_transactions.adoc

@@ -488,8 +488,8 @@ 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
 relaying full nodes; an attacker creating 1,000 replacement transactions
-per minute at 200 bytes each would use about 20 kilobytes of their
+per minute at 200 bytes each would use about 20 KB of their
-personal bandwidth but about 10 gigabytes of full node network bandwidth
+personal bandwidth but about 10 GB of full node network bandwidth
 every minute.  Except for the cost of their 20 KB/minute bandwidth and
 the occasional fee when a transaction got confirmed, the attacker wouldn't
 need to pay any costs for the enormous burden they placed on full node
@@ -601,7 +601,7 @@ The example transaction has two outputs.
 
 The first((("transactions", "outputs", "amount field", id="transaction-output-amount")))((("outputs", "amount field", id="output-transaction-amount")))((("amount field (transaction outputs)", id="amount-field"))) field of a specific output is its _amount_, also called
 "value" in Bitcoin Core.  This is an 8-byte signed integer indicating
-the number of _satoshis_ to transfer.  A satoshi is the smallest unit of
+the number of satoshis to transfer.  A satoshi is the smallest unit of
 bitcoin that can be represented in an onchain Bitcoin transaction.
 There are 100 million satoshis in a bitcoin.
 
@@ -629,8 +629,7 @@ 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
 might rise and make the output uneconomical.
 
-The need for full nodes to keep track of all unspent transaction outputs
+The need for full nodes to keep track of all UTXOs, as described in <<outpoints>>, means that every UTXO makes it
-(UTXOs), as described in <<outpoints>>, means that every UTXO makes it
 slightly harder to run a full node.  For UTXOs containing significant
 value, there's an incentive to eventually spend them, so they aren't a
 problem.  But there's no incentive for the person controlling an
@@ -655,7 +654,7 @@ check whether the policy has changed since publication of this book.
 [TIP]
 ====
 Since Bitcoin's inception, every full node has needed to keep a copy of
-every unspent transaction output (UTXO), but that might not always be
+every UTXO, but that might not always be
 the case.  Several developers have been working on((("Utreexo"))) Utreexo, a project
 that allows full nodes to store a commitment to the set of UTXOs rather
 than the data itself.  A minimal commitment might be only a kilobyte or
@@ -983,14 +982,15 @@ be received to witness programs and spent with the witness structure. The terms
 ++++
 <table id="terms_used_authorization_authentication">
 <caption>Terms used for authorization and authentication data in different parts of Bitcoin</caption>
+<thead>
+<tr>
+<th/>
+<th><p>Authorization</p></th>
+<th><p>Authentication</p></th>
+</tr></thead>
 <tbody>
 <tr>
-<td/>
+<td class="fakeheader"><p><strong>Whitepaper</strong></p></td>
-<td><p><strong>Authorization</strong></p></td>
-<td><p><strong>Authentication</strong></p></td>
-</tr>
-<tr>
-<td><p><strong>Whitepaper</strong></p></td>
 <td><p>Public key</p></td>
 <td><p>Signature</p></td>
 </tr>
@@ -1165,12 +1165,13 @@ creation of uneconomical outputs as described in
 ++++
 <table id="weight_factors">
 <caption>Weight factors for all fields in a Bitcoin transaction</caption>
-<tbody>
+<thead>
 <tr>
-<td><p>Field</p></td>
+<th><p>Field</p></th>
-<td><p>Factor</p></td>
+<th><p>Factor</p></th>
-<td><p>Weight in Alice’s Tx</p></td>
+<th><p>Weight in Alice’s Tx</p></th>
-</tr>
+</tr> </thead>
+<tbody>
 <tr>
 <td><p>Version</p></td>
 <td><p>4</p></td>

ch07_authorization-authentication.adoc

@@ -625,7 +625,7 @@ 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
+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
@@ -910,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+].
 
@@ -1257,9 +1257,9 @@ Try running the script on paper to see how it behaves on the stack.
 
 Let’s look at ((("scripts", "segregated witness", id="script-segwit")))((("segregated witness (segwit)", "scripts and", id="segwit-script")))some of our example transactions and see how they would
 change with segregated witness. We’ll first look at how a
-pay to public key hash (P2PKH) payment can be accomplished as the
+pay to public key hash P2PKH payment can be accomplished as the
 segregated witness program. Then, we’ll look at the segregated witness
-equivalent for pay to script hash (P2SH) scripts. Finally, we’ll look at
+equivalent for P2SH scripts. Finally, we’ll look at
 how both of the preceding segregated witness programs can be embedded
 inside a P2SH script.
 
@@ -1352,10 +1352,10 @@ to the receiver in the manner that the receiver indicated.
 ====
 
 [[p2wsh]]
-===== Pay to witness script hash
+===== Pay to witness script hash (P2WSH)
 
 The ((("scripts", "segregated witness", "P2WSH", id="script-segwit-p2wsh")))((("segregated witness (segwit)", "scripts and", "P2WSH", id="segwit-script-p2wsh")))((("P2WSH (pay to witness script hash)", id="p2wsh-ch7")))((("output scripts", "P2WSH (pay to witness script hash)", id="output-script-p2wsh")))second type of
-segwit v0 witness program corresponds to a pay to script hash (P2SH) script. We
+segwit v0 witness program corresponds to a P2SH script. We
 saw this type of script in <<p2sh>>. In that example, P2SH was used by
 Mohammed's company to express a multisignature script. Payments to
 Mohammed's company were encoded with a script like this:

ch08_signatures.adoc

@@ -344,7 +344,7 @@ curve called the Generator (+G+) (see <<public_key_derivation>>).  Alice uses EC
 multiplication to multiply +G+ by her private key +x+, in which case +x+
 is called a _scalar_ because it scales up +G+.  The result is +xG+,
 which we call Alice's _public key_.  Alice gives her public key to Bob.
-Even though Bob also knows +G+, the Discrete Logarithm Problem prevents Bob from being able to divide +xG+ by +G+ to derive Alice's
+Even though Bob also knows +G+, the DLP prevents Bob from being able to divide +xG+ by +G+ to derive Alice's
 private key.
 
 At some later time, Bob wants Alice to identify herself by proving
@@ -959,7 +959,7 @@ recommends a default signing algorithm.
 BIP340 and RFC6979 can generate _k_ entirely deterministically, meaning the same
 transaction data will always produce the same _k_.  Many wallets do this
 because it makes it easy to write tests to verify their safety-critical
-signing code is producing _k_ values correctly.  RFC6979 also allows
+signing code is producing _k_ values correctly.  BIP340 and RFC6979 both also allow
 including additional data in the calculation.  If that data is entropy,
 then a different _k_ will be produced even if the exact same transaction
 data is signed.  This can increase protection against sidechannel and

ch09_fees.adoc

@@ -125,8 +125,8 @@ fee rates.
 ====
 Be careful ((("absurd fees")))((("excessive fees")))((("transaction fees", "overpaying")))((("overpaying transaction fees")))accepting input for fee rates.  If a user copies and pastes a
 fee rate printed in one denominator into a field using a different
-enumerator, they could overpay fees by 1,000 times.  If they instead
+denominator, they could overpay fees by 1,000 times.  If they instead
-switch the enumerator, they could theoretically overpay by 100,000,000
+switch the denominator, they could theoretically overpay by 100,000,000
 times.  Wallets should make it hard for the user to pay an excessive
 fee rate and may want to prompt the user to confirm any fee rate that was
 not generated by the wallet itself using a trusted data source.

ch10_network.adoc

@@ -312,7 +312,7 @@ Once one or more connections are established, the new node will send an
 neighbors will, in turn, forward the +addr+ message to their neighbors,
 ensuring that the newly connected node becomes well known and better
 connected. Additionally, the newly connected node can send +getaddr+ to
-the neighbors, asking them to return a list of IP addresses of other
+its neighbors, asking them to return a list of IP addresses of other
 peers. That way, a node can find peers to connect to and advertise its
 existence on the network for other nodes to find it.
 <<address_propagation>> shows the address discovery protocol.
@@ -741,7 +741,7 @@ incoming transaction. The full node checks several parts of the
 transaction against the bloom filter, looking for a match including:
 
 * The transaction ID
-* The data components from the locking scripts of each of the transaction outputs (every key and hash in the script)
+* The data components from the scripts of each of the transaction outputs (every key and hash in the script)
 * Each of the transaction inputs
 * Each of the input signature data components (or witness scripts)
 

ch11_blockchain.adoc

@@ -545,7 +545,7 @@ 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
-than a full block (about 2 megabytes ((("blockchain", "merkle trees", startref="blockchain-merkle")))((("merkle trees", startref="merkle-tree-explain")))currently).
+than a full block (about 2 MB ((("blockchain", "merkle trees", startref="blockchain-merkle")))((("merkle trees", startref="merkle-tree-explain")))currently).
 
 === Bitcoin's Test Blockchains
 
@@ -640,9 +640,9 @@ used to test segregated witness features.
 ===== Problems with testnet
 
 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
+uses almost exactly the same PoW security mechanism as
 Bitcoin.  The notable differences for testnet are that its minimum
-difficulty is half that of Bitcoin and it's allowed to include a
+difficulty is half that of Bitcoin and that 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.
 
@@ -693,7 +693,7 @@ start your own signet and connect your software to it.
 Bitcoin Core supports((("Bitcoin Core", "signet")))((("default signet")))((("custom signets"))) a default signet, which we believe to be the most
 widely used signet at the time of writing.  It is currently operated by
 two contributors to that project.  If you start Bitcoin Core with the
-+-signet+ parameter and no other signet-related parameters, this is the
++signet+ parameter and no other signet-related parameters, this is the
 signet you will be using.
 
 As of this writing, the default signet has about 150,000 blocks and is
@@ -769,7 +769,6 @@ too. Let's try the +getblockchaininfo+ command to inspect the regtest
 blockchain:
 
 ----
-git comm
 $ bitcoin-cli -regtest getblockchaininfo
 {
   "chain": "regtest",

ch12_mining.adoc

@@ -58,7 +58,7 @@ 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
 new block and acts as proof that the miner expended significant
-computing effort. The competition to solve the Proof-of-Work algorithm
+computing effort. The competition to solve the proof-of-work algorithm
 to earn the reward and the right to record transactions on the
 blockchain is the basis for Bitcoin's security model.
 
@@ -665,7 +665,7 @@ 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 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
+identifier (txid) and used to build a second merkle tree, the root of
 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
@@ -712,7 +712,7 @@ until the desired hash result appears by chance.
 
 ==== Proof-of-Work Algorithm
 
-A hash((("bitcoins", "mining", "Proof-of-Work algorithm", id="bitcoin-mining-proof")))((("mining", "Proof-of-Work algorithm", id="mining-proof")))((("hash functions", "Proof-of-Work algorithm", id="hash-proof")))((("Proof-of-Work algorithm", id="proof-mining"))) algorithm takes an
+A hash((("bitcoins", "mining", "proof-of-work algorithm", id="bitcoin-mining-proof")))((("mining", "proof-of-work algorithm", id="mining-proof")))((("hash functions", "proof-of-work algorithm", id="hash-proof")))((("proof-of-work algorithm", id="proof-mining"))) algorithm takes an
 arbitrary-length data input and produces a fixed-length deterministic
 result, called a _digest_.  The digest is a digital commitment to the
 input. For any specific input, the resulting digest will always be the
@@ -779,12 +779,12 @@ the next round the target is 11. Players must throw 10 or less to win,
 again an easy task. Let's say a few rounds later the target is down to
 5. Now, more than half the dice throws will exceed the target and
 therefore be invalid. It takes more dice throws to win
-the lower the target gets. Eventually, when the target is 2 (the minimum
+the lower the target gets. Eventually, when the target is 3 (the minimum
 possible), only one throw out of every 36, or about 3% of them, will produce a
 winning result.
 
 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
+dice game is 3, 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 based on a
@@ -833,7 +833,7 @@ _target_. If the hash is not less than the target, the miner will modify
 the nonce (usually just incrementing it by one) and try again. At the
 current difficulty in the Bitcoin network, miners have to try
 a huge number of times before finding a nonce that results in a low
-enough block((("bitcoins", "mining", "Proof-of-Work algorithm", startref="bitcoin-mining-proof")))((("mining", "Proof-of-Work algorithm", startref="mining-proof")))((("hash functions", "Proof-of-Work algorithm", startref="hash-proof")))((("Proof-of-Work algorithm", startref="proof-mining"))) header hash.
+enough block((("bitcoins", "mining", "proof-of-work algorithm", startref="bitcoin-mining-proof")))((("mining", "proof-of-work algorithm", startref="mining-proof")))((("hash functions", "proof-of-work algorithm", startref="hash-proof")))((("proof-of-work algorithm", startref="proof-mining"))) header hash.
 
 [[target_bits]]
 ==== Target Representation
@@ -841,7 +841,7 @@ enough block((("bitcoins", "mining", "Proof-of-Work algorithm", startref="bitcoi
 //TODO:use visual representation like I did on bitcoin.org
 
 
-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
+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
 coefficient/exponent format, with the first two hexadecimal digits for
@@ -890,12 +890,12 @@ 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
-8,496 blocks or once every 59 days, ((("bitcoins", "mining", "target representation", startref="bitcoin-mining-target")))((("mining", "target representation", startref="mining-target")))((("targets", "representation of", startref="target-represent")))((("Proof-of-Work algorithm", "target representation", startref="proof-target")))on average.
+8,496 blocks or once every 59 days, ((("bitcoins", "mining", "target representation", startref="bitcoin-mining-target")))((("mining", "target representation", startref="mining-target")))((("targets", "representation of", startref="target-represent")))((("proof-of-work algorithm", "target representation", startref="proof-target")))on average.
 
 [[target]]
 ==== Retargeting to Adjust Difficulty
 
-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
+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
 difficulty adjustable, who adjusts it, and how?
@@ -998,7 +998,7 @@ 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
-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
+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.
 
 [[mtp]]
@@ -1420,7 +1420,7 @@ Managed pools ((("P2Pool (peer-to-peer mining pool)", id="p2pool")))using Stratu
 the pool operator, who might direct the pool effort to double-spend
 transactions or invalidate blocks (see <<consensus_attacks>>).
 Furthermore, centralized pool servers represent a
-single-point-of-failure. If the pool server is down or is slowed by a
+single point of failure. If the pool server is down or is slowed by a
 denial-of-service attack, the pool miners cannot mine. In 2011, to
 resolve these issues of centralization, a new pool mining method was
 proposed and implemented: P2Pool, a peer-to-peer mining pool without a

ch13_security.adoc

@@ -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 that 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

@@ -17,7 +17,7 @@ When ((("Bitcoin", "as application platform", "primitives, list of", secondary-s
 long term, the Bitcoin system offers certain guarantees, which can be
 used as building blocks to create applications. These include:
 
-No Double-Spend:: The most fundamental guarantee of Bitcoin's
+No double-spend:: The most fundamental guarantee of Bitcoin's
 decentralized consensus algorithm ensures that no UTXO can be spent
 twice in the same valid chain of blocks.
 
@@ -35,7 +35,7 @@ This means that anyone can create a valid transaction with sufficient
 fees and trust they will be able to transmit that transaction and have
 it included in the blockchain at any time.
 
-Secure Timestamping:: The consensus rules reject any block whose
+Secure timestamping:: The consensus rules reject any block whose
 timestamp is too far in the future and attempt to prevent blocks with
 timestamps too far in the past. This ensures that timestamps
 on blocks can be trusted to a certain degree. The timestamp on a block implies an
@@ -64,20 +64,20 @@ a transaction signed by another +SIGHASH+ type cannot be modified
 without invalidating the signature, thus invalidating the transaction
 itself.
 
-Transaction Atomicity:: Bitcoin transactions are atomic. They are either
+Transaction atomicity:: Bitcoin transactions are atomic. They are either
 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.
 
-Discrete (Indivisible) Units of Value:: Transaction outputs are discrete
+Discrete (indivisible) units of value:: Transaction outputs are discrete
 and indivisible units of value. They can either be spent or unspent, in
 full. They cannot be divided or partially spent.
 
-Quorum of Control:: Multisignature constraints in scripts impose a
+Quorum of control:: Multisignature constraints in scripts impose a
 quorum of authorization, predefined in the multisignature scheme. The
 requirement is enforced by the consensus rules.
 
-Timelock/Aging:: Any script clause containing a relative or absolute
+Timelock/aging:: Any script clause containing a relative or absolute
 timelock can only be executed after its age exceeds the time specified.
 
 Replication:: The decentralized storage of the blockchain ensures that
@@ -85,7 +85,7 @@ when a transaction is mined, after sufficient confirmations, it is
 replicated across the network and becomes durable and resilient to power
 loss, data loss, etc.
 
-Forgery Protection:: A transaction can only spend existing, validated
+Forgery protection:: A transaction can only spend existing, validated
 outputs. It is not possible to create or counterfeit value.
 
 Consistency:: In the absence of miner partitions, blocks that are
@@ -94,11 +94,11 @@ with exponentially decreasing likelihood, based on the depth at which
 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
+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

preface.asciidoc

@@ -140,7 +140,7 @@ 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$$[].
 
-Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations is available on:
+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:

theme/epub/epub.css

@@ -1 +1,7 @@
-/* Add your custom CSS styles for the EPUB here */
+td.fakeheader {
+    font-family: "MyriadPro-SemiboldCond" !important;
+    font-weight: 600 !important;
+    color: White !important;
+    background-color: Black !important;
+    border: 0pt solid cmyk(0%,0%,0%,100%);
+  }

theme/pdf/pdf.css

@@ -18,6 +18,15 @@ pre[data-type="programlisting"] {
   font-style: normal;
 }
 
+td.fakeheader {
+  font-family: "MyriadPro-SemiboldCond" !important;
+  font-weight: 600 !important;
+  color: White !important;
+  background-color: Black !important;
+  border: 0pt solid cmyk(0%,0%,0%,100%);
+}
+
+
 
 /*hack to align sidebars to top of page*/
 .less_space {margin-top: 0 !important;}