continued QC1 check

ch02_overview.adoc

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

ch04_keys.adoc

@@ -118,7 +118,7 @@ or repeatable. Bitcoin software uses cryptographically secure random
 number generators to produce 256 bits of entropy.
 
 More precisely, the private key can be any number between +0+ and +n -
-1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less
+1+ inclusive, where n is a constant (n = 1.1578 × 10^77^, slightly less
 than 2^256^) defined as the order of the elliptic curve used in Bitcoin
 (see <<elliptic_curve>>). To create such a key, we randomly pick a
 256-bit number and check that it is less than +n+. In programming terms,
@@ -208,7 +208,6 @@ grid. The +secp256k1+ Bitcoin elliptic curve can be thought of as a much
 more complex pattern of dots on a unfathomably large grid.
 
 [[ecc-over-F17-math]]
-[role="smallersixty"]
 .Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17
 image::images/mbc3_0403.png["ecc-over-F17-math"]
 
@@ -288,7 +287,7 @@ that k is sometimes confusingly called an "exponent" in ((("public key cryptogra
 
 The ((("public keys", "generating", id="public-key-generate")))((("elliptic curve multiplication", id="elliptic-multiply")))public key is calculated from
 the private key using elliptic curve multiplication, which is
-irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a
+irreversible: _K_ = _k_ × _G_, where _k_ is the private key, _G_ is a
 constant point called the _generator point_, and _K_ is the resulting
 public key. The reverse operation, known as "finding the discrete
 logarithm"—calculating _k_ if you know __K__—is as difficult as trying
@@ -319,7 +318,7 @@ bitcoin:
 [latexmath]
 ++++
 \begin{equation}
-{K = k * G}
+{K = k × G}
 \end{equation}
 ++++
 
@@ -829,7 +828,6 @@ addresses. However, the private key is identical for both Bitcoin
 addresses.
 
 [[pubkey_compression]]
-[role="smallerseventy"]
 .Public key compression
 image::images/mbc3_0408.png["pubkey_compression"]
 
@@ -1643,7 +1641,7 @@ represented by symbols in the base58 alphabet. The search for a pattern
 like "1Kids" can be seen as searching for an address in the range from
 +1Kids11111111111111111111111111111+ to
 +1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+. There are approximately 58^29^
-(approximately 1.4 * 10^51^) addresses in that range, all starting with
+(approximately 1.4 × 10^51^) addresses in that range, all starting with
 "1Kids." <<table_4-11>> shows the range of addresses that have the
 prefix 1Kids.
 

ch05_wallets.adoc

@@ -55,7 +55,6 @@ created new key pairs for each transaction, producing wallet databases
 that could only reasonably be backed up using digital media.
 
 [[Type0_wallet]]
-[role="smallersixty"]
 .Nondeterministic key generation: a collection of independently generated keys stored in a wallet database
 image::images/mbc3_0501.png["Non-Deterministic Wallet"]
 
@@ -111,7 +110,6 @@ derived separately from their corresponding private keys, making it
 possible to store private keys more securely than ((("wallets", "key generation", "deterministic", startref="wallet-keygen-determine")))((("key generation", "deterministic", startref="keygen-determine")))((("deterministic key generation", startref="determine-keygen")))((("hash functions", "deterministic key generation", startref="hash-determine")))public keys.
 
 [[Type1_wallet]]
-[role="smallersixty"]
 .Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database
 image::images/mbc3_0502.png["Deterministic Wallet"]
 
@@ -142,7 +140,7 @@ K + (123 * G) == (k + 123) * G
 [TIP]
 ====
 In equations throughout this book, we use a single equals sign for
-operations such as +K = k * G+ where the value of a variable is
+operations such as +K = k × G+ where the value of a variable is
 calculated.  We use a double equals sign to show both sides of an
 equation are equivalent, or that an operation should return false (not
 true) if the two sides aren't equivalent.
@@ -732,7 +730,6 @@ of entropy, adds a checksum, and then maps the entropy to a word list:
 generate a BIP39 recovery code.
 
 [[generating_entropy_and_encoding]]
-[role="smallerseventy"]
 .Generating entropy and encoding as a recovery code
 image::images/mbc3_0504.png["Generating entropy and encoding as a recovery code"]
 
@@ -1047,7 +1044,7 @@ hash is used to create a _master private key_ (m) and a _master chain
 code_ (c).
 
 The master private key (m) then generates a corresponding master public
-key (M) using the normal elliptic curve multiplication process +m * G+
+key (M) using the normal elliptic curve multiplication process __m × G__
 that we saw in <<public_key_derivation>>.
 
 The chain code (c) is used to introduce entropy in the function that

ch06_transactions.adoc

@@ -995,12 +995,12 @@ be received to witness programs and spent with the witness structure. The terms
 <td><p>Signature</p></td>
 </tr>
 <tr>
-<td><p><strong>Original (Legacy)</strong></p></td>
+<td  class="fakeheader"><p><strong>Original (Legacy)</strong></p></td>
 <td><p>Output script</p></td>
 <td><p>Input script</p></td>
 </tr>
 <tr>
-<td><p><strong>Segwit</strong></p></td>
+<td  class="fakeheader"><p><strong>Segwit</strong></p></td>
 <td><p>Witness program</p></td>
 <td><p>Witness structure</p></td>
 </tr>

ch07_authorization-authentication.adoc

@@ -898,7 +898,7 @@ constraint on one transaction that is dependent on the elapsed time from
 the confirmation of a previous transaction. In other words, the clock
 doesn't start counting until the UTXO is recorded on the blockchain.
 This functionality is especially useful in bidirectional state channels
-and Lightning Networks, as we will see in <<state_channels>>.
+and Lightning Networks (LNs), as we will see in <<state_channels>>.
 
 Relative timelocks, like absolute timelocks, are implemented with both a
 transaction-level feature and a script-level opcode. The
@@ -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,7 +1257,7 @@ 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
+ P2PKH payment can be accomplished as the
 segregated witness program. Then, we’ll look at the segregated witness
 equivalent for P2SH scripts. Finally, we’ll look at
 how both of the preceding segregated witness programs can be embedded

ch08_signatures.adoc

@@ -267,7 +267,7 @@ output to the same destination (assuming the extra data for the second
 output was known).
 
 The main expected use for the two ++SIGHASH_ANYPREVOUT++ opcodes is improved
-payment channels, such as those used in the Lightning Network, although
+payment channels, such as those used in the Lightning Network (LN), although
 several other uses have been described.
 
 [NOTE]
@@ -275,7 +275,7 @@ several other uses have been described.
 You will not often see +SIGHASH+ flags presented as an option in a user's
 wallet application.  Simple wallet applications
 sign with [.keep-together]#+SIGHASH_ALL+# flags.  More sophisticated applications, such as
-Lightning Network nodes, may use alternative +SIGHASH+ flags, but they
+LN nodes, may use alternative +SIGHASH+ flags, but they
 use protocols that have been extensively reviewed to understand the
 influence of the alternative ((("digital signatures", "SIGHASH flags", startref="digital-signature-sighash")))((("SIGHASH flags", startref="sighash")))flags.
 ====

ch09_fees.adoc

@@ -437,7 +437,7 @@ limited early version of it may be available by the time this book is
 published.
 
 Package relay is especially important for protocols based on
-time-sensitive presigned transactions, such as Lightning Network.  In
+time-sensitive presigned transactions, such as Lightning Network (LN).  In
 non-cooperative cases, some presigned transactions can't be fee bumped
 using RBF, forcing them to depend on CPFP.  In those protocols, some
 transactions may also be created long before they need to be broadcast,
@@ -517,7 +517,7 @@ To prevent these problems, and other related
 
 Transaction pinning can happen by accident, but it also represents a
 serious vulnerability for multiparty time-sensitive protocols such as
-Lightning Network.  If your counterparty can prevent one of your
+LN.  If your counterparty can prevent one of your
 transactions from confirming by a deadline, they may be able to steal
 money from you.
 
@@ -530,7 +530,7 @@ this writing—https://oreil.ly/300dv[ephemeral anchors].
 [[cpfp_carve_out]]
 === CPFP Carve Out and Anchor Outputs
 
-In 2018, ((("transaction fees", "fee bumping", "CPFP carve outs", id="transaction-fee-bump-carveout")))((("fee bumping", "CPFP carve outs", id="fee-bump-carveout")))((("carve outs (CPFP)", id="carveout")))((("CPFP (child pays for parent) fee bumping", "carve outs", id="cpfp-carveout")))developers working on Lightning Network (LN) had a problem.
+In 2018, ((("transaction fees", "fee bumping", "CPFP carve outs", id="transaction-fee-bump-carveout")))((("fee bumping", "CPFP carve outs", id="fee-bump-carveout")))((("carve outs (CPFP)", id="carveout")))((("CPFP (child pays for parent) fee bumping", "carve outs", id="cpfp-carveout")))developers working on LN had a problem.
 Their protocol uses transactions that require signatures from two
 different parties.  Neither party wants to trust the other, so they sign
 transactions at a point in the protocol when trust isn't needed,

ch10_network.adoc

@@ -175,7 +175,7 @@ quickly announcing blocks).
 
 // released into the public domain by Nicolas Dorier
 [[bip152_illustration]]
-.BIP152 modes compared (from BIP152).  The gray bar indicates the time it takes the node to validate the block.
+.BIP152 modes compared (from BIP152).  The shaded bar indicates the time it takes the node to validate the block.
 image::images/mbc3_1002.png["BIP152"]
 
 The names of the two methods (which are taken from BIP152) can be a bit
@@ -683,7 +683,6 @@ image::images/mbc3_1007.png["Bloom2"]
 <<bloom3>> is an example of adding a second pattern "B" to the simple bloom filter.
 
 [[bloom3]]
-[role="smallereighty"]
 .Adding a second pattern "B" to our simple bloom filter
 image::images/mbc3_1008.png["Bloom3"]
 
@@ -700,7 +699,6 @@ simple bloom filter. The corresponding bits are set to +1+, so the
 pattern is probably a match.
 
 [[bloom4]]
-[role="smallereighty"]
 .Testing the existence of pattern "X" in the bloom filter. The result is a probabilistic positive match, meaning "Maybe."
 image::images/mbc3_1009.png["Bloom4"]
 

ch11_blockchain.adoc

@@ -450,6 +450,7 @@ transactions leading to the same merkle root. For example, the two
 trees in <<cve_tree>>:
 
 [[cve_tree]]
+[.width-90]
 .Two Bitcoin-style merkle tree with the same root but a different number of leaves
 image::images/mbc3_1104.png["Two Bitcoin-style merkle trees with the same root but a different number of leaves"]
 
@@ -640,7 +641,7 @@ 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 PoW security mechanism as
+uses almost exactly the same proof-of-work security mechanism as
 Bitcoin.  The notable differences for testnet are that its minimum
 difficulty is half that of Bitcoin and that it's allowed to include a
 block at the minimum difficulty if that block's timestamp is more than

ch14_applications.adoc

@@ -275,7 +275,7 @@ Developers ((("colored coins application", "RGB protocol", id="color-coin-rgb"))
 modern Bitcoin-based colored coin protocols.  A primary requirement of
 the design for RGB was making the protocol compatible with offchain
 payment channels (see <<state_channels>>), such as those used in
-Lightning Network.  That's accomplished at each layer of the RGB
+Lightning Network (LN).  That's accomplished at each layer of the RGB
 protocol:
 
 Single-use seals:: 
@@ -323,8 +323,8 @@ by Bitcoin is bitcoin.
 ====
 
 Even more than RGB, Taproot Assets has been designed to be compatible
-with Lightning Network.  One challenge with forwarding nonbitcoin assets
-over Lightning Network is that there are two ways to accomplish the
+with LN.  One challenge with forwarding nonbitcoin assets
+over LN is that there are two ways to accomplish the
 sending, each with a different set of trade-offs:
 
 Native forwarding::
@@ -971,10 +971,10 @@ know the((("Bitcoin", "as application platform", "payment channels", secondary-s
 [[lightning_network]]
 === Routed Payment Channels (Lightning Network)
 
-The((("Bitcoin", "as application platform", "routed payment channels (Lightning Network)", secondary-sortas="application platform", id="bitcoin-app-platform-ln")))((("application platform, Bitcoin as", "routed payment channels (Lightning Network)", id="app-platform-ln")))((("payment channels", "Lightning Network", id="payment-channel-ln")))((("Lightning Network", id="lightning")))((("routed payment channels", see="Lightning Network"))) Lightning Network is a proposed routed network of
+The((("Bitcoin", "as application platform", "routed payment channels (Lightning Network)", secondary-sortas="application platform", id="bitcoin-app-platform-ln")))((("application platform, Bitcoin as", "routed payment channels (Lightning Network)", id="app-platform-ln")))((("payment channels", "Lightning Network", id="payment-channel-ln")))((("Lightning Network", id="lightning")))((("routed payment channels", see="Lightning Network"))) Lightning Network (LN) is a proposed routed network of
 bidirectional payment channels connected end-to-end. A network like this
 can allow any participant to route a payment from channel to channel
-without trusting any of the intermediaries. The Lightning Network was
+without trusting any of the intermediaries. The LN was
 https://oreil.ly/NM8LC[first described by
 Joseph Poon and Thadeus Dryja in February 2015], building on the concept
 of payment channels as proposed and elaborated upon by many others.

preface.asciidoc

@@ -125,6 +125,7 @@ Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[].
 
 === Contacting the Authors
 
+[.align]
 You can contact Andreas M. Antonopoulos on his personal site:
 [.keep-together]#link:$$https://antonopoulos.com$$[].#
 

theme/pdf/pdf.css

@@ -34,34 +34,33 @@ td.fakeheader {
 .less_space_heading > h2 {margin-top: 0 !important;}
 .less_space_h1 > h1 {margin-top: 0 !important;}
 
-/*Image resizing*/
-figure.smallerninetyfive img { width: 95%; }
+/* Variable widths */
+:not(figure).width-10,
+figure.width-10 img { width: 10% !important; }
+:not(figure).width-20,
+figure.width-20 img { width: 20% !important; }
+:not(figure).width-25,
+figure.width-25 img { width: 25% !important; }
+:not(figure).width-30,
+figure.width-30 img { width: 30% !important; }
+:not(figure).width-40,
+figure.width-40 img { width: 40% !important; }
+:not(figure).width-50,
+figure.width-50 img { width: 50% !important; }
+:not(figure).width-60,
+figure.width-60 img { width: 60% !important; }
+:not(figure).width-70,
+figure.width-70 img { width: 70% !important; }
+:not(figure).width-75,
+figure.width-75 img { width: 75% !important; }
+:not(figure).width-80,
+figure.width-80 img { width: 80% !important; }
+:not(figure).width-90,
+figure.width-90 img,
+figure.width-ninety img { width: 90% !important; }
+:not(figure).width-100,
+figure.width-100 img { width: 100% !important; }
 
-figure.smallerninety img { width: 90%; }
-
-figure.smallereightyfive img { width: 85%; }
-
-figure.smallereighty img { width: 80%; }
-
-figure.smallerseventyfive img { width: 75%; }
-
-figure.smallerseventy img { width: 70%; }
-
-figure.smallersixtyfive img { width: 65%; }
-
-figure.smallersixty img { width: 60%; }
-
-figure.smallerfiftyfive img { width: 55%; }
-
-figure.smallerfifty img { width: 50%; }
-
-figure.smallerfourtyfive img { width: 45%; }
-
-figure.smallerfourty img { width: 40%; }
-
-figure.smallerthirtyfive img { width: 35%; }
-
-figure.smallerthirty img { width: 30%; }
 
 /*class to adjust the space of code listings to fix page break*/
 pre.c_less_space {