diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc
index 4971d0ec..54751770 100644
--- a/ch05_wallets.adoc
+++ b/ch05_wallets.adoc
@@ -147,7 +147,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}
 ++++
 
diff --git a/ch12_mining.adoc b/ch12_mining.adoc
index 88c4e4a5..4e419e8b 100644
--- a/ch12_mining.adoc
+++ b/ch12_mining.adoc
@@ -1715,7 +1715,7 @@ transactions, the miners on the "a" chain cannot process it. To them it
 appears to be an invalid block, as its parent "7b" is not recognized as a
 ((("consensus rules", "hard forks", "explained", startref="consensus-hard-fork")))((("forks", "hard forks", "explained", startref="forks-hard")))((("hard forks", "explained", startref="hard-forks-ch12")))valid block.
 
-==== Hard Forks: Software, Network, Mining, and Chain
+===== Hard forks: Software, network, mining, and chain
 
 For ((("software forks", id="software-fork")))((("network forks", id="network-fork")))((("mining forks", id="mining-fork")))((("chain forks", id="chain-fork")))((("consensus rules", "hard forks", "types of", id="consensus-hard-fork-type")))((("forks", "hard forks", "types of", id="forks-hard-type")))((("hard forks", "types of", id="hard-forks-type")))software
 developers, the term "fork" has another meaning, adding confusion to the
@@ -1776,7 +1776,7 @@ partitioned network will make it so that the miners operating on
 separate consensus rules won't likely receive each other's blocks, as
 they are connected to two separate ((("software forks", startref="software-fork")))((("network forks", startref="network-fork")))((("mining forks", startref="mining-fork")))((("chain forks", startref="chain-fork")))((("consensus rules", "hard forks", "types of", startref="consensus-hard-fork-type")))((("forks", "hard forks", "types of", startref="forks-hard-type")))((("hard forks", "types of", startref="hard-forks-type")))networks.
 
-==== Diverging Miners and Difficulty
+===== Diverging miners and difficulty
 
 As miners ((("consensus rules", "hard forks", "difficulty and", id="consensus-hard-fork-difficult")))((("forks", "hard forks", "difficulty and", id="forks-hard-difficult")))((("hard forks", "difficulty and", id="hard-forks-difficult")))((("difficulty", "hard forks and", id="difficulty-hardfork")))diverge into mining two different chains, the
 hashing power is split between the chains. The mining power can be split
@@ -1808,7 +1808,7 @@ or approximately 10 weeks to mine. Assuming a fixed capacity per block,
 this will also result in a reduction of transaction capacity by a factor
 of 5, as there are fewer blocks per hour available to record transactions.
 
-==== Contentious Hard Forks
+===== Contentious hard forks
 
 This is ((("consensus rules", "hard forks", "contentious forks")))((("forks", "hard forks", "contentious forks")))((("hard forks", "contentious forks")))((("contentious hard forks")))the dawn of the development of software
 for decentralized consensus. Just as other innovations in development changed both the methods
@@ -1875,7 +1875,7 @@ is a soft fork because a transaction that is valid under BIP65 is also
 valid on any client that is not implementing (ignorant of) BIP65. To
 the old clients, the script contains an NOP code, which is((("consensus rules", "soft forks", "explained", startref="consensus-soft-explain")))((("forks", "soft forks", "explained", startref="fork-soft-explain")))((("soft forks", "explained", startref="soft-fork-explain"))) ignored.
 
-==== Criticisms of Soft Forks
+===== Criticisms of soft forks
 
 Soft forks ((("consensus rules", "soft forks", "criticisms of", id="consensus-soft-critic")))((("forks", "soft forks", "criticisms of", id="fork-soft-critic")))((("soft forks", "criticisms of", id="soft-fork-critic")))based on the NOP opcodes are
 relatively uncontroversial. The NOP opcodes were placed in Bitcoin
@@ -1908,7 +1908,7 @@ fork that had to be reversed because of a bug would almost certainly
 lead to loss of funds.
 
 [[softforksignaling]]
-=== Soft Fork Signaling with Block Version
+===== Soft fork signaling with block version
 
 Since soft forks allow
 unmodified clients to continue to operate within consensus, one
@@ -1918,7 +1918,7 @@ all miners enforce the new rules, there's no risk of unmodified
 nodes accepting a block that upgraded nodes would reject.
 This mechanism was introduced by BIP34.
 
-==== BIP34 Signaling and Activation
+===== BIP34: Signaling and activation
 
 BIP34 used ((("consensus rules", "soft forks", "BIP34 signaling/activation", tertiary-sortas="BIP034", id="consensus-soft-bip34")))((("forks", "soft forks", "BIP34 signaling/activation", tertiary-sortas="BIP034", id="fork-soft-bip34")))((("soft forks", "BIP34 signaling/activation", secondary-sortas="BIP034", id="soft-fork-bip34")))((("signaling", "BIP34", secondary-sortas="BIP034", id="signal-bip34")))((("activation (soft forks)", "BIP34", secondary-sortas="BIP034", id="activation-bip34")))((("BIP34 signaling/activation", primary-sortas="BIP034", id="bip34")))the block version
 field to allow miners to signal readiness for a specific consensus rule
@@ -1975,7 +1975,7 @@ of BIP34 was retired and replaced with ((("consensus rules", "soft forks", "BIP3
 described next.
 
 [[bip9]]
-==== BIP9 Signaling and Activation
+===== BIP9: Signaling and activation
 
 The ((("consensus rules", "soft forks", "BIP9 signaling/activation", tertiary-sortas="BIP009", id="consensus-soft-bip9")))((("forks", "soft forks", "BIP9 signaling/activation", tertiary-sortas="BIP009", id="fork-soft-bip9")))((("soft forks", "BIP9 signaling/activation", secondary-sortas="BIP009", id="soft-fork-bip9")))((("signaling", "BIP9", secondary-sortas="BIP009", id="signal-bip9")))((("activation (soft forks)", "BIP9", secondary-sortas="BIP009", id="activation-bip9")))((("BIP9 signaling/activation", primary-sortas="BIP009", id="bip9-ch12")))mechanism used by BIP34, BIP66, and BIP65 was
 successful in activating three soft forks. However, it was replaced
@@ -2073,7 +2073,7 @@ The ((("consensus rules", "soft forks", "BIP9 signaling/activation", tertiary-so
 https://oreil.ly/FoCsz[BIP9
 (Version bits with timeout and delay)].
 
-=== BIP8: Mandatory Lock-in with Early Activation
+===== BIP8: Mandatory lock-in with early activation
 
 After((("consensus rules", "soft forks", "BIP8 mandatory lock-in", tertiary-sortas="BIP008", id="consensus-soft-bip8")))((("forks", "soft forks", "BIP8 mandatory lock-in", tertiary-sortas="BIP008", id="fork-soft-bip8")))((("soft forks", "BIP8 mandatory lock-in", secondary-sortas="BIP008", id="soft-fork-bip8")))((("activation (soft forks)", "BIP8", secondary-sortas="BIP008", id="activate-soft-fork-bip8")))((("BIP8 mandatory lock-in", primary-sortas="BIP008", id="bip8")))((("mandatory lock-in", id="mandatory-lockin")))((("lock-in, mandatory", id="lockin-mandatory")))((("segregated witness (segwit)", id="segwit-bip8"))) BIP9 was successfully used for the CSV-related soft fork, the next
 implementation of a soft fork consensus change also attempted to use it
@@ -2126,7 +2126,7 @@ running BIP8.  Unfortunately, there's no way to prove what would have
 happened, and so we can't say for sure how much BIP8 contributed to the
 activation of((("consensus rules", "soft forks", "BIP8 mandatory lock-in", tertiary-sortas="BIP008", startref="consensus-soft-bip8")))((("forks", "soft forks", "BIP8 mandatory lock-in", tertiary-sortas="BIP008", startref="fork-soft-bip8")))((("soft forks", "BIP8 mandatory lock-in", secondary-sortas="BIP008", startref="soft-fork-bip8")))((("activation (soft forks)", "BIP8", secondary-sortas="BIP008", startref="activate-soft-fork-bip8")))((("BIP8 mandatory lock-in", primary-sortas="BIP008", startref="bip8")))((("mandatory lock-in", startref="mandatory-lockin")))((("lock-in, mandatory", startref="lockin-mandatory")))((("segregated witness (segwit)", startref="segwit-bip8"))) taproot.
 
-=== Speedy Trial: Fail Fast or Succeed Eventually
+===== Speedy trial: Fail fast or succeed eventually
 
 Although ((("consensus rules", "soft forks", "speedy trial activation", id="consensus-soft-speed")))((("forks", "soft forks", "speedy trial activation", id="fork-soft-speed")))((("soft forks", "speedy trial activation", id="soft-fork-speed")))((("speedy trial activation", id="speed-trial")))((("activation (soft forks)", "speedy trial", id="activation-speed")))BIP9 by itself did not seem to result in the activation of
 segwit despite widespread support for the proposal, it was unclear to
@@ -2154,7 +2154,7 @@ a clear success.  Others were still disappointed that BIP8 wasn't used.
 It's not clear whether or not speedy trial will be used again for a
 future attempt to activate a ((("consensus rules", "soft forks", "speedy trial activation", startref="consensus-soft-speed")))((("forks", "soft forks", "speedy trial activation", startref="fork-soft-speed")))((("soft forks", "speedy trial activation", startref="soft-fork-speed")))((("speedy trial activation", startref="speed-trial")))((("activation (soft forks)", "speedy trial", startref="activation-speed")))soft fork.
 
-=== Consensus Software Development
+==== Consensus Software Development
 
 Consensus software((("consensus rules", "software development")))((("software development for consensus rules")))((("forks", "consensus rule software development"))) continues to evolve, and there is much
 discussion on the various mechanisms for changing the consensus rules.