QC1 and math check

appb_errata.adoc

@@ -36,12 +36,12 @@ occurred in July 2010, long after Bitcoin’s initial release:
 -    if (pindexNew->nHeight > nBestHeight)
 +    if (pindexNew->bnChainWork > bnBestChainWork)
 ----
-* *Terminology change:* General CPUs were used to generate the POW for
-the earliest Bitcoin blocks, but POW generation today is mostly performed
+* *Terminology change:* General CPUs were used to generate the PoW for
+the earliest Bitcoin blocks, but PoW generation today is mostly performed
 by specialist Application Specific Integrated Circuits (ASICs), so
 instead of saying "CPU power" it is perhaps more correct to say
 "computational power" or, simply, "hash rate" for the hashing used
-in generating the POW.
+in generating the PoW.
 
 ____
 "As long as a majority of CPU power is controlled by nodes that are not

ch01_intro.adoc

@@ -133,7 +133,7 @@ computing, known as the "Byzantine Generals' Problem." Briefly, the
 problem consists of trying to get multiple participants without a leader
 to agree on a course of action by exchanging information over an
 unreliable and potentially compromised network. Satoshi Nakamoto's solution, which uses the concept of
-Proof-of-Work to achieve consensus _without a central trusted
+proof of work to achieve consensus _without a central trusted
 authority_, represents a breakthrough in distributed computing.
 ****
 

ch02_overview.adoc

@@ -14,8 +14,7 @@ transactions, the network, and mining.
 
 === Bitcoin Overview
 
-In the ((("Bitcoin", "operational overview", id="bitcoin-operational-overview-ch2")))((("blockchain explorers", id="blockchain-explorers")))overview diagram shown in <<bitcoin-overview>>, we see that the
-Bitcoin system consists of users with wallets containing keys,
+The ((("Bitcoin", "operational overview", id="bitcoin-operational-overview-ch2")))((("blockchain explorers", id="blockchain-explorers")))Bitcoin system consists of users with wallets containing keys,
 transactions that are propagated across the network, and miners who
 produce (through competitive computation) the consensus blockchain,
 which is the authoritative journal of all transactions.
@@ -30,10 +29,6 @@ application that operates as a Bitcoin search engine, in that it allows
 you to search for addresses, transactions, and blocks and see the
 relationships and flows between them.
 
-[[bitcoin-overview]]
-.Bitcoin overview
-image::images/mbc3_0201.png["Bitcoin Overview"]
-
 Popular blockchain explorers include:
 
 * https://blockstream.info[Blockstream Explorer]

ch04_keys.adoc

@@ -63,10 +63,10 @@ from the private key, so storing only the private key is also possible.
 
 A Bitcoin wallet contains a collection of key
 pairs, each consisting of a private key and a public key. The private
-key (k) is a number, usually derived from a number picked at random.
+key (_k_) is a number, usually derived from a number picked at random.
 From the private key, we
 use elliptic curve multiplication, a one-way cryptographic function, to
-generate a public((("public key cryptography", startref="pub-key")))((("key pairs", startref="key-pair"))) key (K).
+generate a public((("public key cryptography", startref="pub-key")))((("key pairs", startref="key-pair"))) key (_K_).
 
 .Why Use Asymmetric Cryptography (Public/Private Keys)?
 ****
@@ -118,15 +118,15 @@ 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,
+256-bit number and check that it is less than _n_. In programming terms,
 this is usually achieved by feeding a larger string of random bits,
 collected from a cryptographically secure source of randomness, into the
 SHA256 hash algorithm, which will conveniently produce a 256-bit value
 that can be interpreted as a number.
-If the result is less than +n+, we have a suitable private key.
+If the result is less than _n_, we have a suitable private key.
 Otherwise, we simply try again with another random number.
 
 [WARNING]
@@ -140,7 +140,7 @@ choose to make sure it is cryptographically secure. Correct
 implementation of the CSPRNG is critical to the security of the keys.
 ====
 
-The following is a randomly generated private key (k) shown in
+The following is a randomly generated private key (_k_) shown in
 hexadecimal format (256 bits shown as 64 hexadecimal digits, each 4
 bits):
 
@@ -167,7 +167,7 @@ curve.
 by Bitcoin.
 
 [[ecc-curve]]
-[role="width-80"]
+[role="width-50"]
 .An elliptic curve
 image::images/mbc3_0402.png["ecc-curve"]
 
@@ -341,12 +341,10 @@ Implementing the elliptic curve multiplication, we take the private key
 _k_ generated previously and multiply it with the generator point _G_ to
 find the public key _K_:
 
-[latexmath]
-++++
-\begin{equation}
-{K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD \times G}
-\end{equation}
-++++
+[source, python]
+----
+K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD * G
+----
 
 Public key _K_ is defined as a point K = (x, y):
 
@@ -1087,7 +1085,7 @@ The "32" stands for the number of characters in the bech32 alphabet
 .Bech32 typo detection
 ====
 Address:
-  bc1p9nh05ha8wrljf7ru236aw**n**4t2x0d5ctkkywm**v**9sclnm4t0av2vgs4k3au7
+  bc1p9nh05ha8wrljf7ru236awpass:[<u>n</u>]4t2x0d5ctkkywm**v**9sclnm4t0av2vgs4k3au7
 
 Detected errors shown in bold.  Generated using the
 https://oreil.ly/paWIx[bech32 address decoder demo].
@@ -1633,7 +1631,7 @@ Once a vanity address matching the desired pattern is found, the private
 key from which it was derived can be used by the owner to spend bitcoins
 in exactly the same way as any other address. Vanity addresses are no
 less or more secure than any other address. They depend on the same
-elliptic curve cryptography (ECC) and SHA as any other address. You can
+elliptic curve cryptography (ECC) and secure hash algorithm (SHA) as any other address. You can
 no more easily find the private key of an address starting with a vanity
 pattern than you can any other address.
 

ch05_wallets.adoc

@@ -141,7 +141,7 @@ simply adding the same value to both sides of the equation:
 [latexmath]
 ++++
 \begin{equation}
-K + (123 \times G) == (k + 123) \times G
+K + (123 \times G) =\!= (k + 123) \times G
 \end{equation}
 ++++
 
@@ -149,13 +149,13 @@ K + (123 \times G) == (k + 123) \times 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.
 ====
 
-An interesting consequence of this is that adding `123` to the public
+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
 private key, but he does know the global constant _G_, so he can add any
@@ -1053,7 +1053,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
@@ -1318,11 +1318,6 @@ To export the xpub from his Trezor hardware signing device, Gabriel uses
 the web-based Trezor wallet application. The Trezor device must be plugged in
 for the public keys to be exported. Note that most hardware signing devices will
 never export private keys--those always remain on the device.
-<<export_xpub>> shows the web interface Gabriel uses to export the xpub.
-
-[[export_xpub]]
-.Exporting an xpub from a Trezor hardware signing device
-image::images/mbc3_0509.png["Exporting the xpub from the Trezor"]
 
 Gabriel copies the xpub to his web store's Bitcoin payment processing
 software, such as the widely used open source BTCPay Server.

ch06_transactions.adoc

@@ -228,22 +228,22 @@ unsigned integers:
 </thead>
 <tbody>
 <tr>
-<td><p>&gt;= <code>0</code> &amp;&amp; &lt;= <code>252</code> (<code>0xfc</code>)</p></td>
+<td><p>≥ <code>0</code> &amp;&amp; ≤ <code>252</code> (<code>0xfc</code>)</p></td>
 <td><p><code>1</code></p></td>
 <td><p><code>uint8_t</code></p></td>
 </tr>
 <tr>
-<td><p>&gt;= <code>253</code> &amp;&amp; &lt;= <code>0xffff</code></p></td>
+<td><p>≥ <code>253</code> &amp;&amp; ≤ <code>0xffff</code></p></td>
 <td><p>3</p></td>
 <td><p><code>0xfd</code> followed by the number as <code>uint16_t</code></p></td>
 </tr>
 <tr>
-<td><p>&gt;= <code>0x10000</code> &amp;&amp; &lt;= <code>0xffffffff</code></p></td>
+<td><p>≥ <code>0x10000</code> &amp;&amp; ≤ <code>0xffffffff</code></p></td>
 <td><p><code>5</code></p></td>
 <td><p><code>0xfe</code> followed by the number as <code>uint32_t</code></p></td>
 </tr>
 <tr>
-<td><p>&gt;= <code>0x100000000</code> &amp;&amp; &lt;= <code>0xffffffffffffffff</code></p></td>
+<td><p>≥ <code>0x100000000</code> &amp;&amp; ≤ <code>0xffffffffffffffff</code></p></td>
 <td><p><code>9</code></p></td>
 <td><p><code>0xff</code> followed by the number as <code>uint64_t</code></p></td>
 </tr>
@@ -276,7 +276,7 @@ control over bitcoins is assigned in transaction outputs, Alice _points_
 to the previous _output_ using an _outpoint_ field.  Each input must
 contain a single outpoint.
 
-The outpoint contains a 32-byte transaction identifier (_txid_) for the
+The outpoint contains a 32-byte txid for the
 transaction where Alice received the bitcoins she now wants to spend.
 This txid is in Bitcoin's internal byte order for hashes; see
 <<internal_and_display_order>>.
@@ -325,7 +325,7 @@ Different approaches to tracking previous outputs have been tried by
 different full node implementations at various times.  Bitcoin Core
 currently uses the solution believed to be most effective at retaining
 all necessary information while minimizing disk space: it keeps a
-database that stores every unspent transaction output (UTXO) and
+database that stores every UTXO and
 essential metadata about it (like its confirmation block height).  Each
 time a new block of transactions arrives, all of the outputs they spend
 are removed from the UTXO database and all of the outputs they create
@@ -986,23 +986,23 @@ be received to witness programs and spent with the witness structure. The terms
 <tr>
 <th/>
 <th><p>Authorization</p></th>
-<th><p>Authentication</p></th>
+<th class="right"><p>Authentication</p></th>
 </tr></thead>
 <tbody>
 <tr>
 <td class="fakeheader"><p><strong>Whitepaper</strong></p></td>
 <td><p>Public key</p></td>
-<td><p>Signature</p></td>
+<td class="right"><p>Signature</p></td>
 </tr>
 <tr>
 <td  class="fakeheader"><p><strong>Original (Legacy)</strong></p></td>
 <td><p>Output script</p></td>
-<td><p>Input script</p></td>
+<td class="right"><p>Input script</p></td>
 </tr>
 <tr>
 <td  class="fakeheader"><p><strong>Segwit</strong></p></td>
 <td><p>Witness program</p></td>
-<td><p>Witness structure</p></td>
+<td class="right"><p>Witness structure</p></td>
 </tr>
 </tbody>
 </table>

ch07_authorization-authentication.adoc

@@ -1383,8 +1383,7 @@ satisfy that redeem script, all inside the transaction input:
 
 Now, let's look at how this entire example would be upgraded to segwit v0.
 If Mohammed's customers were using a segwit-compatible wallet, they
-would make a payment, creating a pay to witness script hash (P2WSH)
-output that would look like this:
+would make a payment, creating a P2WSH output that would look like this:
 
 .Example P2WSH output script
 ----

ch08_signatures.adoc

@@ -409,7 +409,7 @@ brute force is easy; the numbers used in Bitcoin are much larger.
 Let's discuss some of the features of the interactive schnorr
 identity protocol that make it secure:
 
-The nonce ([.plain]#k#)::
+The nonce (k)::
 In step 1, ((("digital signatures", "schnorr signature algorithm", "security features")))((("schnorr signature algorithm", "security features")))Alice chooses a number that Bob doesn't
   know and can't guess and gives him the scaled form of that number,
   _kG_.  At that point, Bob also already has her public key (_xG_),
@@ -424,7 +424,7 @@ In step 1, ((("digital signatures", "schnorr signature algorithm", "security fea
   be able to leverage that into figuring out Alice's private key.  See
   <<nonce_warning>> for more details.
 
-The challenge scalar ([.plain]#e#)::
+The challenge scalar (e)::
 Bob waits to receive Alice's public nonce
   and then proceeds in step 2 to give her a number (the challenge
   scalar) that Alice didn't previously know and couldn't have guessed.
@@ -674,8 +674,7 @@ MuSig2::
   This only ((("MuSig2 protocol")))requires two rounds of communication and can sometimes allow
   one of the rounds to be combined with key exchange.  This can
   significantly speed up signing for certain protocols, such as how
-  scriptless multisignatures are planned to be used in the Lightning
-  Network.  MuSig2 is specified in BIP327 (the only scriptless
+  scriptless multisignatures are planned to be used in the LN.  MuSig2 is specified in BIP327 (the only scriptless
   multisignature protocol that has a BIP as of this writing).
 
 MuSig-DN::
@@ -903,7 +902,7 @@ the following DER-encoded signature:
 b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301
 ----
 
-That signature is a serialized byte stream of the +R+ and _s_ values
+That signature is a serialized byte stream of the _R_ and _s_ values
 produced by the signer to prove control of the private key authorized
 to spend an output. The serialization format consists of nine elements
 as follows:

ch09_fees.adoc

@@ -590,7 +590,7 @@ miners:
 [latexmath]
 ++++
 \begin{equation}
-{Fees = Sum(Inputs) – Sum(Outputs)}
+{Fees = Sum(Inputs) - Sum(Outputs)}
 \end{equation}
 ++++
 

ch12_mining.adoc

@@ -385,7 +385,7 @@ transaction fees:
 [latexmath]
 ++++
 \begin{equation}
-Total Fees = Sum(Inputs) - Sum(Outputs)
+Total\:Fees = Sum(Inputs) - Sum(Outputs)
 \end{equation}
 ++++
 
@@ -858,7 +858,7 @@ is:
 
 ++++
 <ul class="simplelist">
-  <li>target = coefficient * 2<sup>(8*(exponent–3))</sup></li>
+  <li>target = coefficient * 2<sup>(8*(exponent – 3))</sup></li>
 </ul>
 ++++
 
@@ -866,9 +866,7 @@ Using that formula, and the difficulty bits value 0x1903a30c, we get:
 
 ++++
 <ul class="simplelist">
-  <li>target = 0x03a30c * 2<sup>0x08*(0x19-0x03)</sup></li>
-  <li>=> target = 0x03a30c * 2<sup>(0x08*0x16)</sup></li>
-  <li>=> target = 0x03a30c * 2<sup>0xB0</sup></li>
+  <li>target = 0x03a30c × 2<sup>0x08 × (0x19 - 0x03)</sup></li>
 </ul>
 ++++
 
@@ -876,16 +874,15 @@ which in decimal is:
 
 ++++
 <ul class="simplelist">
-  <li>=> target = 238,348 * 2<sup>176</sup></li>
-  <li>=> target = <br/>22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328</li>
+  <li>22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328</li>
 </ul>
 ++++
 
-switching back to hexadecimal:
+Or, in hexadecimal:
 
 ++++
 <ul class="simplelist">
-  <li>=> target = <br/>0x0000000000000003A30C00000000000000000000000000000000000000000000</li>
+  <li>0x0000000000000003A30C00000000000000000000000000000000000000000000</li>
 </ul>
 ++++
 
@@ -944,7 +941,7 @@ resulting in a retargeting bias toward higher difficulty by 0.05%.
 <<retarget_code>> shows the code used in the Bitcoin Core client.
 
 [[retarget_code]]
-.Retargeting the proof of work&#x2014;[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
+.Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
 ====
 [source,cpp]
 ----

ch14_applications.adoc

@@ -339,9 +339,8 @@ Translated forwarding::
   support forwarding bitcoin payments.
 
 Native forwarding is conceptually simpler but essentially requires a
-separate Lightning Network for every asset.  Translated forwarding
-allows building on the economies of scale of the Bitcoin Lightning
-Network, but it may be vulnerable to a problem called((("free American call option"))) the _free American
+separate LN for every asset.  Translated forwarding
+allows building on the economies of scale of the Bitcoin LN, but it may be vulnerable to a problem called((("free American call option"))) the _free American
 call option_, where a receiver may selectively accept or reject certain
 payments depending on recent changes to the exchange rate in order to
 siphon money from the hop next to them.  Although there's no known
@@ -712,8 +711,7 @@ Even though a transaction cannot be canceled, it can be constructed in
 such a way as to make it undesirable to use. The way we do that is by
 giving each party a _revocation key_ that can be used to punish the
 other party if they try to cheat. This mechanism for revoking prior
-commitment transactions was first proposed as part of the Lightning
-Network.
+commitment transactions was first proposed as part of the LN.
 
 To explain revocation keys, we will construct a more complex payment
 channel between two exchanges run by Hitesh and Irene. Hitesh and Irene
@@ -909,8 +907,7 @@ Asymmetric revocable commitments with relative time locks (+CSV+) are a
 much better way to implement payment channels and a very significant
 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
+commitment transactions. In implementations of LN, the commitment state is identified by a 48-bit index, allowing
 more than 281 trillion (2.8 × 10^14^) state transitions in ((("payment channels", "asymmetric revocable commitments", startref="payment-channel-revoke")))((("asymmetric revocable commitments", startref="asymmetric-revoke-commit")))((("commitment transactions", "asymmetric revocable commitments", startref="commit-revoke")))((("revocable commitments", startref="revoke-commit")))any single
 channel.
 
@@ -996,12 +993,11 @@ to Carol, Carol to Diana, and Diana to Eric. For simplicity let's assume
 each channel is funded with 2 bitcoins by each participant, for a total
 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
+<<lightning_network_fig>> shows five participants in an LN, connected by bidirectional payment channels that can be linked
 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
+.A series of bidirectional payment channels linked to form an LN that can route a payment from Alice to Eric
 image::images/mbc3_1406.png["A series of bi-directional payment channels linked to form a Lightning Network"]
 
 Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to
@@ -1015,10 +1011,10 @@ payment from Alice to Eric, through a series of HTLC commitments on the
 payment channels connecting the participants.
 
 [[ln_payment_process]]
-.Step-by-step payment routing through a Lightning Network
+.Step-by-step payment routing through an LN
 image::images/mbc3_1407.png["Step-by-step payment routing through a Lightning Network"]
 
-Alice is running a Lightning Network (LN) node that is keeping track of
+Alice is running an LN node that is keeping track of
 her payment channel to Bob and has the ability to discover routes
 between payment channels. Alice's LN node also has the ability to
 connect over the internet to Eric's LN node. Eric's LN node creates a
@@ -1114,7 +1110,7 @@ with sufficient capacity. Nodes advertise routing information, including
 what channels they have open, how much capacity each channel has, and
 what fees they charge to route payments. The routing information can be
 shared in a variety of ways, and different pathfinding protocols have
-emerged as Lightning Network technology has advanced.
+emerged as LN technology has advanced.
 Current implementations of
 route discovery use a P2P model where nodes propagate channel
 announcements to their peers in a "flooding" model, similar to how
@@ -1132,15 +1128,15 @@ Carol's perspective, this looks like a payment from Bob to Diana. Carol
 does not know that Bob is actually relaying a payment from Alice. She
 also doesn't know that Diana will be relaying a payment to Eric.
 
-This is a critical feature of the Lightning Network because it ensures
+This is a critical feature of the LN because it ensures
 privacy of payments and makes it difficult to apply surveillance,
 censorship, or blacklists. But how does Alice establish this payment
 path without revealing anything to the intermediary nodes?
 
-The Lightning Network implements an onion-routed protocol based on a
+The LN implements an onion-routed protocol based on a
 scheme called https://oreil.ly/fuCiK[Sphinx]. This routing protocol
 ensures that a payment sender can construct and communicate a path
-through the Lightning Network such that:
+through the LN such that:
 
 - Intermediate nodes can verify and decrypt their portion of route
   information and find the next hop.
@@ -1192,40 +1188,39 @@ hops to go.
 
 ==== Lightning Network Benefits
 
-A((("payment channels", "Lightning Network", "benefits of", id="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", id="lightning-benefits"))) Lightning Network is a
+An((("payment channels", "Lightning Network", "benefits of", id="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", id="lightning-benefits"))) LN is a
 second-layer routing technology. It can be applied to any blockchain
 that supports some basic capabilities, such as multisignature
 transactions, timelocks, and basic smart contracts.
 
-Lightning Network is layered on top of the Bitcoin network, giving
+LN is layered on top of the Bitcoin network, giving
 Bitcoin a significant increase in capacity, privacy,
 granularity, and speed, without sacrificing the principles of trustless
 operation without intermediaries:
 
-Privacy:: Lightning Network payments are much more private than payments
+Privacy:: LN payments are much more private than payments
 on the Bitcoin blockchain, as they are not public. While participants in
 a route can see payments propagated across their channels, they do not
 know the sender or recipient.
 
-Fungibility:: A Lightning Network makes it much more difficult to apply
+Fungibility:: An LN makes it much more difficult to apply
 surveillance and blacklists on Bitcoin, increasing the fungibility of
 the currency.
 
-Speed:: Bitcoin transactions using Lightning Network are settled in
+Speed:: Bitcoin transactions using LN are settled in
 milliseconds, rather than minutes or hours, as HTLCs are cleared without
 committing transactions to a block.
 
-Granularity:: A Lightning Network can enable payments at least as small
+Granularity:: An LN can enable payments at least as small
 as the Bitcoin "dust" limit, perhaps even smaller.
 
-Capacity:: A Lightning Network increases the capacity of the Bitcoin
+Capacity:: An LN increases the capacity of the Bitcoin
 system by several orders of magnitude. The upper bound
 to the number of payments per second that can be routed over a Lightning
 Network depends only on the capacity and speed of each node.
 
-Trustless Operation:: A Lightning Network uses Bitcoin transactions
-between nodes that operate as peers without trusting each other. Thus, a
-Lightning Network preserves the principles of the Bitcoin system, while
+Trustless Operation:: An LN uses Bitcoin transactions
+between nodes that operate as peers without trusting each other. Thus, an LN preserves the principles of the Bitcoin system, while
 expanding its operating parameters ((("Bitcoin", "as application platform", "routed payment channels (Lightning Network)", secondary-sortas="application platform", startref="bitcoin-app-platform-ln")))((("application platform, Bitcoin as", "routed payment channels (Lightning Network)", startref="app-platform-ln")))((("payment channels", "Lightning Network", startref="payment-channel-ln")))((("Lightning Network", startref="lightning")))((("payment channels", "Lightning Network", "benefits of", startref="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", startref="lightning-benefits")))significantly.
 
 We have examined just a few of the emerging applications that can be

preface.asciidoc

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

theme/epub/epub.css

@@ -4,4 +4,7 @@ td.fakeheader {
     color: White !important;
     background-color: Black !important;
     border: 0pt solid cmyk(0%,0%,0%,100%);
-  }
+  }
+
+  /*--Table lines--*/
+table td.right, th.right { border-right: 0.25pt solid cmyk(0%,0%,0%,100%); }

theme/pdf/pdf.css

@@ -18,6 +18,10 @@ pre[data-type="programlisting"] {
   font-style: normal;
 }
 
+/*--Table lines--*/
+table td.right, th.right { border-right: 0.25pt solid cmyk(0%,0%,0%,100%); }
+
+
 td.fakeheader {
   font-family: "MyriadPro-SemiboldCond" !important;
   font-weight: 600 !important;