periods in image captions

7 months ago · 599394a35e
parent f9b7a6087f
commit 599394a35e
11 changed files with 69 additions and 69 deletions
--- a/ch01_intro.adoc
+++ b/ch01_intro.adoc
@ -383,7 +383,7 @@ Alice((("bitcoins", "receiving")))((("receiving bitcoins"))) uses the _Receive_

 [role="width-50"]
 [[wallet_receive]]
-.Alice uses the Receive screen on her mobile Bitcoin wallet and displays her address in a QR code format
+.Alice uses the Receive screen on her mobile Bitcoin wallet and displays her address in a QR code format.
 image::images/mbc3_0101.png["Wallet receive screen with QR code displayed.  Image derived from Bitcoin Design Guide CC-BY"]

 The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera.
@ -475,7 +475,7 @@ prompt him with a suggested fee (or fee rate).  The higher the transaction fee,
 faster the transaction will be confirmed (see <<confirmations>>).

 [[wallet-send]]
-.Bitcoin wallet send screen
+.Bitcoin wallet send screen.
 image::images/mbc3_0102.png["Wallet send screen.  Image derived from Bitcoin Design Guide CC-BY"]

 Joe then carefully checks to make sure he has entered the correct
--- a/ch02_overview.adoc
+++ b/ch02_overview.adoc
@ -89,7 +89,7 @@ TODO: Replace QR code with test-BTC address
 ////

 [[invoice-QR]]
-.Invoice QR code
+.Invoice QR code.
 image::images/mbc3_0201.png["payment-request"]

 Unlike a QR code that simply contains a destination Bitcoin address, this
@ -177,7 +177,7 @@ is signing a transaction that transfers value from a previous
 transaction over to a new owner identified by a Bitcoin ((("transactions", "inputs", startref="transaction-input-ch2")))((("transactions", "outputs", startref="transaction-output-ch2")))((("inputs", startref="input")))((("outputs", startref="output")))address.

 [[transaction-double-entry]]
-.Transaction as double-entry bookkeeping
+.Transaction as double-entry bookkeeping.
 image::images/mbc3_0202.png["Transaction Double-Entry"]

 ==== Transaction Chains
@ -223,7 +223,7 @@ change.
 ////

 [[transaction-chain]]
-.A chain of transactions, where the output of one transaction is the input of the next transaction
+.A chain of transactions, where the output of one transaction is the input of the next transaction.
 image::images/mbc3_0203.png["Transaction chain"]

 [TIP]
@ -295,7 +295,7 @@ transaction has one input and two outputs and is shown in
 <<transaction-common>>.

 [[transaction-common]]
-.Most common transaction
+.Most common transaction.
 image::images/mbc3_0204.png["Common Transaction"]

 Another common form of transaction ((("consolidation transactions")))is a _consolidation transaction_, which spends several inputs
@ -305,7 +305,7 @@ notes for a single larger note. Transactions like these are sometimes
 generated by wallets and businesses to clean up lots of smaller amounts.

 [[transaction-consolidating]]
-.Consolidation transaction aggregating funds
+.Consolidation transaction aggregating funds.
 image::images/mbc3_0205.png["Aggregating Transaction"]

 Finally, another transaction form that is seen often on the
@ -316,7 +316,7 @@ distribute funds, such as when processing payroll payments to multiple((("transa
 employees.

 [[transaction-distributing]]
-.Batch transaction distributing funds
+.Batch transaction distributing funds.
 image::images/mbc3_0206.png["Distributing Transaction"]

 === Constructing a Transaction
@ -589,7 +589,7 @@ the process of mining and the way it builds confidence in more ((("bitcoins", "m
 <<mining>>.

 [[block-alice1]]
-.Alice's transaction included in a block
+.Alice's transaction included in a block.
 image::images/mbc3_0207.png["Alice's transaction included in a block"]

 [role="less_space pagebreak-before"]
@ -618,7 +618,7 @@ for a new website page. Now the chain of transactions will
 look like <<block-alice2>>.

 [[block-alice2]]
-.Alice's transaction as part of a transaction chain from Joe to Gopesh
+.Alice's transaction as part of a transaction chain from Joe to Gopesh.
 image::images/mbc3_0208.png["Alice's transaction as part of a transaction chain"]

 In this chapter, we((("transactions", "spending bitcoins", startref="transaction-spend2")))((("bitcoins", "spending", startref="bitcoin-spend2")))((("spending bitcoins", startref="spend-bitcoin2"))) saw how transactions build a chain that moves value
--- a/ch03_bitcoin-core.adoc
+++ b/ch03_bitcoin-core.adoc
@ -52,7 +52,7 @@ of Bitcoin peer-to-peer communication.
 Core.

 [[bitcoin_core_architecture]]
-.Bitcoin Core architecture (Source: Eric Lombrozo)
+.Bitcoin Core architecture (Source: Eric Lombrozo).
 image::images/mbc3_0301.png["Bitcoin Core Architecture"]

 Although Bitcoin Core serves as a reference implementation for many
--- a/ch04_keys.adoc
+++ b/ch04_keys.adoc
@ -13,7 +13,7 @@ The original Bitcoin paper describes a very simple scheme for achieving
 those goals, shown in <<pay-to-pure-pubkey>>.  

 [[pay-to-pure-pubkey]]
-.Transaction chain from original Bitcoin paper
+.Transaction chain from original Bitcoin paper.
 image::images/mbc3_aain01.png["Transaction chain from original Bitcoin paper"]

 A receiver like Bob
@ -172,7 +172,7 @@ by Bitcoin.

 [[ecc-curve]]
 [role="width-50"]
-.An elliptic curve
+.An elliptic curve.
 image::images/mbc3_0402.png["ecc-curve"]

 Bitcoin uses a specific elliptic curve and set of mathematical
@ -212,7 +212,7 @@ 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]]
-.Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17
+.Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17.
 image::images/mbc3_0403.png["ecc-over-F17-math"]

 So, for example, the following is a point P with coordinates (x, y) that
@ -389,7 +389,7 @@ library] to do the elliptic curve((("public keys", "generating", startref="publi
 ====

 [[ecc_illustrated]]
-.Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve
+.Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve.
 image::images/mbc3_0404.png["ecc_illustrated"]

 === Output and Input Scripts
@ -432,7 +432,7 @@ better understand why certain features may have been added to the
 Bitcoin protocol.

 [[bitcoin_01_send]]
-.Early send screen for Bitcoin via https://oreil.ly/IDV1a[The Internet Archive]
+.Early send screen for Bitcoin via https://oreil.ly/IDV1a[The Internet Archive].
 image::images/mbc3_0405.png["Early Bitcoin send screen"]

 If Alice entered Bob's IP address in Bitcoin 0.1, her full node would
@ -688,7 +688,7 @@ previously. <<base58check_encoding>> illustrates the base58check
 encoding process.

 [[base58check_encoding]]
-.Base58check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data
+.Base58check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data.
 image::images/mbc3_0406.png["Base58CheckEncoding"]

 ++++
@ -757,7 +757,7 @@ encoding, <<pubkey_to_address>> illustrates the conversion of a public key
 into a Bitcoin ((("public key cryptography", "base58check encoding", startref="pub-key-base58")))((("base58check encoding", startref="base58-ch4")))((("encoding", "base58check", startref="encode-base58")))((("version prefixes", startref="version-prefix")))address.

 [[pubkey_to_address]]
-.Public key to Bitcoin address: conversion of a public key to a Bitcoin address
+.Public key to Bitcoin address: conversion of a public key to a Bitcoin address.
 image::images/mbc3_0407.png["pubkey_to_address"]

 [[comp_pub]]
@ -827,7 +827,7 @@ point. Public key compression is illustrated in <<pubkey_compression>>.


 [[pubkey_compression]]
-.Public key compression
+.Public key compression.
 image::images/mbc3_0408.png["pubkey_compression"]


@ -1113,7 +1113,7 @@ https://oreil.ly/paWIx[bech32 address decoder demo].
  <<bech32_qrcode_uc_lc>>.

 [[bech32_qrcode_uc_lc]]
-.The same bech32 address QR encoded in lowercase and uppercase
+.The same bech32 address QR encoded in lowercase and uppercase.
 image::images/mbc3_0409.png["The same bech32 address QR encoded in lowercase and uppercase"]

 - Bech32 takes advantage of an upgrade mechanism designed as part of
@ -1858,7 +1858,7 @@ Paper wallets come in many designs and sizes, with many different
 features. <<paper_wallet_simple>> shows a sample paper wallet.

 [[paper_wallet_simple]]
-.An example of a simple paper wallet
+.An example of a simple paper wallet.
 image::images/mbc3_0410.png[]

 Some are intended to be given as gifts and have seasonal themes, such as
--- a/ch05_wallets.adoc
+++ b/ch05_wallets.adoc
@ -60,7 +60,7 @@ that could only reasonably be backed up using digital media.

 [[Type0_wallet]]
 [role="width-60"]
-.Nondeterministic key generation: a collection of independently generated keys stored in a wallet database
+.Nondeterministic key generation: a collection of independently generated keys stored in a wallet database.
 image::images/mbc3_0501.png["Non-Deterministic Wallet"]

 Modern wallet applications don't independently generate keys but instead
@ -116,7 +116,7 @@ possible to store private keys more securely than ((("wallets", "key generation"

 [[Type1_wallet]]
 [role="width-70"]
-.Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database
+.Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database.
 image::images/mbc3_0502.png["Deterministic Wallet"]


@ -210,7 +210,7 @@ limit on the depth of the tree.  This tree structure is illustrated in
 <<Type2_wallet>>.

 [[Type2_wallet]]
-.HD wallet: a tree of keys generated from a single seed
+.HD wallet: a tree of keys generated from a single seed.
 image::images/mbc3_0503.png["HD wallet"]

 The tree structure can be used to express additional
@ -748,7 +748,7 @@ of entropy, adds a checksum, and then maps the entropy to a word list:
 generate a BIP39 recovery code.

 [[generating_entropy_and_encoding]]
-.Generating entropy and encoding as a recovery code
+.Generating entropy and encoding as a recovery code.
 image::images/mbc3_0504.png["Generating entropy and encoding as a recovery code"]

 <<table_4-5>> shows the relationship between the size of the entropy
@ -859,7 +859,7 @@ described previously in <<generating_recovery_words>>:
 <<fig_5_7>> shows how a recovery code is used to generate a seed.

 [[fig_5_7]]
-.From recovery code to seed
+.From recovery code to seed.
 image::images/mbc3_0505.png["From recovery code to seed"]


@ -1057,7 +1057,7 @@ seed is derived from. The process of creating the master keys and master chain c
 wallet is shown in <<HDWalletFromSeed>>.

 [[HDWalletFromSeed]]
-.Creating master keys and chain code from a root seed
+.Creating master keys and chain code from a root seed.
 image::images/mbc3_0506.png["HDWalletFromRootSeed"]

 The root seed is input into the HMAC-SHA512 algorithm and the resulting
@ -1103,7 +1103,7 @@ index set to 0 to produce the "zero" (first by index) child of the
 parent.

 [[CKDpriv]]
-.Extending a parent private key to create a child private key
+.Extending a parent private key to create a child private key.
 image::images/mbc3_0507.png["ChildPrivateDerivation"]

 Changing the index allows us to extend the parent and create the other
@ -1284,7 +1284,7 @@ the hardware signing device. <<CKDpub>> illustrates the
 mechanism for extending a parent public key to derive child ((("wallets", "key generation", "HD (hierarchical deterministic)", startref="wallet-keygen-hd")))((("key generation", "HD (hierarchical deterministic)", startref="keygen-hd")))((("HD (hierarchical deterministic) key generation", startref="hd-keygen")))((("BIP32 HD (hierarchical deterministic) key generation", startref="bip32")))((("seeds", "HD wallet creation", startref="seed-hdwallet")))((("key generation", "HD (hierarchical deterministic)", "public child key derivation", startref="keygen-hd-public-child")))((("HD (hierarchical deterministic) key generation", "public child key derivation", startref="hd-keygen-public-child")))((("public child key derivation", startref="public-child")))((("child key pair derivation", "public keys", startref="child-key-pair-public")))public keys.

 [[CKDpub]]
-.Extending a parent public key to create a child public key
+.Extending a parent public key to create a child public key.
 image::images/mbc3_0508.png["ChildPublicDerivation"]

 ==== Using an Extended Public Key on a Web Store
@ -1360,7 +1360,7 @@ parent private key is used as input to the hash function, instead of the
 parent public key, as shown in the diagram in <<CKDprime>>.

 [[CKDprime]]
-.Hardened derivation of a child key; omits the parent public key
+.Hardened derivation of a child key; omits the parent public key.
 image::images/mbc3_0509.png["ChildHardPrivateDerivation"]


--- a/ch06_transactions.adoc
+++ b/ch06_transactions.adoc
@ -83,7 +83,7 @@ top-level fields.  We'll examine each of them in the order they appear
 in the transaction and describe any additional fields that they((("transactions", "serialized", startref="transaction-serialize")))((("serialized transactions", startref="serial-transactions")))((("Bitcoin Core", "serialized transactions", startref="bitcoin-core-serial-transaction"))) contain.

 [[alice_tx_byte_map]]
-.A byte map of Alice's transaction
+.A byte map of Alice's transaction.
 image::images/mbc3_0601.png["A byte map of Alice's transaction"]

 [[version]]
@ -179,7 +179,7 @@ The((("transactions", "inputs", id="transaction-input")))((("inputs", id="input-
 map of those bytes in <<alice_tx_input_map>>.

 [[alice_tx_input_map]]
-.Map of bytes in the inputs field of Alice's transaction
+.Map of bytes in the inputs field of Alice's transaction.
 image::images/mbc3_0602.png["map of bytes in the inputs field of Alice's transaction"]

 ==== Length of Transaction Input List
@ -575,7 +575,7 @@ maximum relative timelock in both blocks and seconds from 16 bits
 as defined by BIP68.

 [[bip_68_def_of_nseq]]
-.BIP68 definition of sequence encoding (Source: BIP68)
+.BIP68 definition of sequence encoding (Source: BIP68).
 image::images/mbc3_0603.png["BIP68 definition of sequence encoding"]

 Note that any transaction that sets a relative timelock using sequence
@ -591,7 +591,7 @@ transaction where Alice pays Bob, displayed as
 a map of those bytes in <<output-byte-map>>.

 [[output-byte-map]]
-.A byte map of the outputs field from Alice's transaction
+.A byte map of the outputs field from Alice's transaction.
 image::images/mbc3_0604.png["A byte map of the outputs field from Alice's transaction"]

 ==== Outputs Count
@ -1020,7 +1020,7 @@ other fields, so we'll start with a map of those bytes from
 Alice's transaction in <<alice_tx_witness_map>>.

 [[alice_tx_witness_map]]
-.A byte map of the witness structure from Alice's transaction
+.A byte map of the witness structure from Alice's transaction.
 image::images/mbc3_0605.png["A byte map of the witness from Alice's transaction"]

 Unlike the inputs and outputs fields, the overall witness structure doesn't
@ -1261,7 +1261,7 @@ this chapter is shown represented in weight units in
 the difference in size between the various fields in the ((("transactions", "weights", startref="transactions-weight")))((("weights (of transactions)", startref="weights")))((("vbytes", startref="vbytes")))two images.

 [[alice_tx_weight_map]]
-.A byte map of Alice's transaction
+.A byte map of Alice's transaction.
 image::images/mbc3_0606.png["A weight map of Alice's transaction"]

 [[legacy_serialization]]
--- a/ch07_authorization-authentication.adoc
+++ b/ch07_authorization-authentication.adoc
@ -129,7 +129,7 @@ from the concatenation of the scripts prior((("scripts", "input/output", "constr
 validation.

 [[input_and_output_scripts_legacy]]
-.Combining input and output scripts to evaluate a transaction script
+.Combining input and output scripts to evaluate a transaction script.
 image::images/mbc3_0701.png["input_and_output_scripts"]

 ===== The script execution stack
@ -201,7 +201,7 @@ to know that the number 2 satisfies the script.


 [[simplemath_script]]
-.Bitcoin's script validation doing simple math
+.Bitcoin's script validation doing simple math.
 image::images/mbc3_0702.png["TxScriptSimpleMathExample"]

 [TIP]
@ -302,11 +302,11 @@ execution of the combined script, which will prove this is a valid
 transaction.

 [[P2PubKHash1]]
-.Evaluating a script for a P2PKH transaction (part 1 of 2)
+.Evaluating a script for a P2PKH transaction (part 1 of 2).
 image::images/mbc3_0703.png["Tx_Script_P2PubKeyHash_1"]

 [[P2PubKHash2]]
-.Evaluating a script for a P2PKH transaction (part 2 of 2)
+.Evaluating a script for a P2PKH transaction (part 2 of 2).
 image::images/mbc3_0704.png["Tx_Script_P2PubKeyHash_2"]

 [[multisig]]
@ -1630,7 +1630,7 @@ from <<variable_timelock_multisig>>, we construct a merkle tree for each
 of the three authorization conditions in <<diagram_mast1>>.

 [[diagram_mast1]]
-.A MAST with three subscripts
+.A MAST with three subscripts.
 image::images/mbc3_0705.png["A MAST with three sub-scripts"]

 We can now create a compact membership proof that proves a particular
@ -1641,7 +1641,7 @@ computed from other data provided by the user, so they don't need to be
 specified at spend time.

 [[diagram_mast2]]
-.A MAST membership proof for one of the subscripts
+.A MAST membership proof for one of the subscripts.
 image::images/mbc3_0706.png["A MAST membership proof for one of the sub-scripts"]

 [role="less_space pagebreak-before"]
@ -1672,7 +1672,7 @@ conditions only exist in case something goes wrong.  We can restructure
 our tree with this knowledge as shown in <<diagram_mast3>>.

 [[diagram_mast3]]
-.A MAST with the most-expected script in the best position
+.A MAST with the most-expected script in the best position.
 image::images/mbc3_0707.png["A MAST with the most-expected script in the best position"]

 [role="less_space pagebreak-before"]
@ -1702,7 +1702,7 @@ _merklized abstract syntax trees_.  In an abstract syntax tree (AST),
 every condition in a script creates a new branch, as show in <<ast>>.

 [[ast]]
-.An abstract syntax tree (AST) for a script
+.An abstract syntax tree (AST) for a script.
 image::images/mbc3_0708.png["An Abstract Syntax Tree (AST) for a script"]

 ASTs are widely used by programs that parse and optimize code for other
@ -1719,7 +1719,7 @@ one of them complete by itself, where only one can be selected--making
 them alternatives for each other, as shown in <<alt_script>>.

 [[alt_script]]
-.An alternative script tree
+.An alternative script tree.
 image::images/mbc3_0709.png["An alternative script tree"]

 Alternative script trees only require revealing one 32-byte digest for
@ -1902,7 +1902,7 @@ revealing the MAST branch we want to use.  That commitment tree
 involving both a public key and a MAST is shown in <<diagram_taproot1>>.

 [[diagram_taproot1]]
-.A taproot with the public key committing to a merkle root
+.A taproot with the public key committing to a merkle root.
 image::images/mbc3_0710.png["A taproot with the public key committing to a merkle root"]

 This makes the mutual satisfaction clause using a multisignature
--- a/ch10_network.adoc
+++ b/ch10_network.adoc
@ -108,7 +108,7 @@ the time between when one miner announces a new block and when other
 miners receive that block.

 [[mining_race]]
-.A blockchain fork requiring a mining race
+.A blockchain fork requiring a mining race.
 image::images/mbc3_1001.png["Mining race"]

 In 2015, a new version of Bitcoin Core added a feature called
@ -307,7 +307,7 @@ is used to form introductions, the client will disconnect from it and
 use the newly discovered peers.

 [[network_handshake]]
-.The initial handshake between peers
+.The initial handshake between peers.
 image::images/mbc3_1003.png["NetworkHandshake"]

 Once one or more connections are established, the new node will send an
@ -322,7 +322,7 @@ existence on the network for other nodes to find it.


 [[address_propagation]]
-.Address propagation and discovery
+.Address propagation and discovery.
 image::images/mbc3_1004.png["AddressPropagation"]

 A node must connect to a few different peers in order to establish
@ -580,7 +580,7 @@ using a single +headers+ message.  See the illustration in
 <<spv_synchronization>>.

 [[spv_synchronization]]
-.Lightweight client synchronizing the block headers
+.Lightweight client synchronizing the block headers.
 image::images/mbc3_1005.png["Header synchronization"]

 Block headers allow a lightweight client to verify that any individual block
@ -649,7 +649,7 @@ In <<bloom1>>, we use a very small array of 16 bits and a set of three
 hash functions to demonstrate how bloom filters work.

 [[bloom1]]
-.An example of a simplistic bloom filter, with a 16-bit field and three hash functions
+.An example of a simplistic bloom filter, with a 16-bit field and three hash functions.
 image::images/mbc3_1006.png["Bloom1"]

 The bloom filter is initialized so that the array of bits is all zeros.
@ -680,13 +680,13 @@ array or fewer hash functions will record fewer patterns and produce
 less accuracy.

 [[bloom2]]
-.Adding a pattern "A" to our simple bloom filter
+.Adding a pattern "A" to our simple bloom filter.
 image::images/mbc3_1007.png["Bloom2"]

 <<bloom3>> is an example of adding a second pattern "B" to the simple bloom filter.

 [[bloom3]]
-.Adding a second pattern "B" to our simple bloom filter
+.Adding a second pattern "B" to our simple bloom filter.
 image::images/mbc3_1008.png["Bloom3"]

 [role="less_space pagebreak-before"]
--- a/ch11_blockchain.adoc
+++ b/ch11_blockchain.adoc
@ -354,7 +354,7 @@ chain, making the blockchain longer with a new height of 277,315.
 references in((("blockchain", "linking blocks", startref="blockchain-link")))((("blocks", "linking in blockchain", startref="block-link")))((("linking blocks in blockchain", startref="link-block"))) the +previousblockhash+ field.

 [[chain_of_blocks]]
-.Blocks linked in a chain by each referencing the previous block header hash
+.Blocks linked in a chain by each referencing the previous block header hash.
 image::images/mbc3_1101.png[]

 [[merkle_trees]]
@ -418,7 +418,7 @@ header and summarizes all the data in all four transactions.
 of the nodes.

 [[simple_merkle]]
-.Calculating the nodes in a merkle tree
+.Calculating the nodes in a merkle tree.
 image::images/mbc3_1102.png["merkle_tree"]

 Because the merkle tree is a binary tree, it needs
@ -430,7 +430,7 @@ Similarly, if there are an odd number of hashes to process at any level,
 the last hash is duplicated.

 [[merkle_tree_odd]]
-.Duplicating one data element achieves an even number of data elements
+.Duplicating one data element achieves an even number of data elements.
 image::images/mbc3_1103.png["merkle_tree_odd"]

 .A Design Flaw in Bitcoin's Merkle Tree
@ -454,7 +454,7 @@ trees in <<cve_tree>>:

 [[cve_tree]]
 [role="width-90"]
-.Two Bitcoin-style merkle trees with the same root but a different number of leaves
+.Two Bitcoin-style merkle trees 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"]

 The transaction lists [1,2,3,4,5,6] and [1,2,3,4,5,6,5,6] (where 5 and
@ -500,7 +500,7 @@ transaction out of more than a thousand transactions in a multimegabyte
 block.

 [[merkle_tree_large]]
-.A merkle tree summarizing many data elements
+.A merkle tree summarizing many data elements.
 image::images/mbc3_1105.png["merkle_tree_large"]

 In <<merkle_tree_path>>, a node can prove that a transaction K is
@ -515,7 +515,7 @@ H~IJKLMNOP~, and the merkle tree root (outlined in a dashed line in the
 diagram).

 [[merkle_tree_path]]
-.A merkle path used to prove inclusion of a data element
+.A merkle path used to prove inclusion of a data element.
 image::images/mbc3_1106.png["merkle_tree_path"]

 The efficiency of merkle trees becomes obvious as the scale increases.
--- a/ch12_mining.adoc
+++ b/ch12_mining.adoc
@ -120,7 +120,7 @@ miners will be rewarded solely through the transaction fees.
 time, as the issuance of currency decreases.

 [[bitcoin_money_supply]]
-.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate
+.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate.
 image::images/mbc3_1201.png["BitcoinMoneySupply"]

 [NOTE]
@ -1683,7 +1683,7 @@ we saw in <<forks>>. With the mining of block 5, the network converges
 on one chain and the fork is resolved.

 [[blockchainwithforks]]
-.A blockchain with forks
+.A blockchain with forks.
 image::images/mbc3_1202.png[A blockchain with forks]

 Later, however, at block height 6,
@ -2065,7 +2065,7 @@ proposal state changes to +FAILED+, indicating a rejected proposal.
 +FAILED+ proposals remain in that state perpetually.

 [[bip9states]]
-.BIP9 state transition diagram
+.BIP9 state transition diagram.
 image::images/mbc3_1203.png[BIP9 Proposal State Transition Diagram]

 BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+
--- a/ch14_applications.adoc
+++ b/ch14_applications.adoc
@ -444,7 +444,7 @@ else or submitted to the blockchain.
 showing the funding, commitment, and settlement ((("payment channels", "state channels", startref="payment-channel-state")))((("state channels", startref="state-channel-terminology")))((("transactions", "state channels", startref="transaction-state")))transactions.

 [[payment_channel]]
-.A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions
+.A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions.
 image::images/mbc3_1401.png["A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions"]

 ==== Simple Payment Channel Example
@ -470,7 +470,7 @@ Fabian. <<emma_fabian_streaming_video>> shows Emma buying the video
 streaming service from Fabian using a payment channel.

 [[emma_fabian_streaming_video]]
-.Emma purchases streaming video from Fabian with a payment channel, paying for each second of video
+.Emma purchases streaming video from Fabian with a payment channel, paying for each second of video.
 image::images/mbc3_1402.png["Emma purchases streaming video from Fabian with a payment channel, paying for each second of video"]

 In this example, Fabian and Emma are using special software that handles
@ -546,7 +546,7 @@ transaction that allocated the final balance correctly between((("payment channe
 participants.

 [[video_payment_channel]]
-.Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel
+.Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel.
 image::images/mbc3_1403.png["Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel"]

 ==== Making Trustless Channels
@ -612,7 +612,7 @@ shorter timelock, allowing it to be spent before the previous
 commitments become valid.

 [[timelocked_commitments]]
-.Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid
+.Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid.
 image::images/mbc3_1404.png["Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid"]

 Each subsequent commitment transaction must have a shorter timelock so
@ -802,7 +802,7 @@ isn't enough to encourage fair conduct.
 where the output paying the holder of the commitment is delayed.

 [[asymmetric_commitments]]
-.Two asymmetric commitment transactions with delayed payment for the party holding the transaction
+.Two asymmetric commitment transactions with delayed payment for the party holding the transaction.
 image::images/mbc3_1405.png["Two asymmetric commitment transactions with delayed payment for the party holding the transaction"]

 Now we introduce the final element of this scheme: a revocation key that
@ -1005,7 +1005,7 @@ capacity of 4 bitcoins in each channel.
 to make a payment from Alice to Eric (see <<lightning_network>>).

 [[lightning_network_fig]]
-.A series of bidirectional payment channels linked to form an LN 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
@ -1019,7 +1019,7 @@ 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 an LN
+.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 an LN node that is keeping track of