OTD check

ch04_keys.adoc

@@ -881,15 +881,19 @@ was simply that the input script needed to provide an appropriate
 signature.  In <<addresses_for_p2pkh>>, an appropriate public key also needed to be
 provided.
 
+++++
+<p class="fix_tracking">
 For a spender (like Alice) to place the constraints Bob wants
 in the output script she uses to pay him, Bob needs to communicate those
 constraints to her.  This is similar to the problem of Bob needing to
 communicate his public key to her.  Like that problem, where
 public keys can be fairly large, the constraints Bob uses can also be
-quite large--potentially thousands of bytes.  That's not only thousands
+quite large—potentially thousands of bytes.  That's not only thousands
 of bytes that need to be communicated to Alice, but thousands of bytes
 for which she needs to pay transaction fees every time she wants to spend money to Bob.  However, the solution of using hash functions to create
 small commitments to large amounts of data also applies here.
+</p>
+++++
 
 The BIP16 upgrade to the Bitcoin protocol in 2012 allows an
 output script to ((("redeem scripts", id="redeem-script")))commit to a _redemption script_ (_redeem script_).  When

ch11_blockchain.adoc

@@ -439,10 +439,7 @@ An extended comment in Bitcoin Core's source code, reproduced here with slight r
 significant problem in the design of Bitcoin's duplication of odd
 elements in its merkle tree:
 
-++++
-<p data-type="attribution">Bitcoin Core <em>src/consensus/merkle.cpp</em></p>
-++++
-[quote,Bitcoin Core src/consensus/merkle.cpp]
+
 ____
 WARNING! If you're reading this because you're learning about crypto
 and/or designing a new system that will use merkle trees, keep in mind
@@ -475,6 +472,10 @@ together, and treating that identically to the block having an invalid
 merkle root. Assuming no double-SHA256 collisions, this will detect all
 known ways of changing the transactions without affecting the merkle
 root.
+
+++++
+<p data-type="attribution">Bitcoin Core <em>src/consensus/merkle.cpp</em></p>
+++++
 ____
 
 ****

ch12_mining.adoc

@@ -940,12 +940,6 @@ slower than expected, the difficulty decreases (target increases).
 The equation can be summarized as:
 
 
-[latexmath]
-++++
-\begin{equation}
-New\:Target = Old\:Target \times (20,160 minutes / Actual Time of Last 2015 Blocks)
-\end{equation}
-++++
 ----
 New Target = Old Target * (20,160 minutes / Actual Time of Last 2015 Blocks)
 ----
@@ -1981,6 +1975,7 @@ After the activation of BIP65, the signaling and activation mechanism
 of BIP34 was retired and replaced with ((("consensus rules", "soft forks", "BIP34 signaling/activation", tertiary-sortas="BIP034", startref="consensus-soft-bip34")))((("forks", "soft forks", "BIP34 signaling/activation", tertiary-sortas="BIP034", startref="fork-soft-bip34")))((("soft forks", "BIP34 signaling/activation", secondary-sortas="BIP034", startref="soft-fork-bip34")))((("signaling", "BIP34", secondary-sortas="BIP034", startref="signal-bip34")))((("activation (soft forks)", "BIP34", secondary-sortas="BIP034", startref="activation-bip34")))((("BIP34 signaling/activation", primary-sortas="BIP034", startref="bip34")))the BIP9 signaling mechanism
 described next.
 
+[role="less_space pagebreak-before"]
 [[bip9]]
 ===== BIP9: Signaling and activation
 
@@ -2160,7 +2155,7 @@ activated about six months later.  To proponents of speedy trial, it was
 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.
+future attempt to activate a soft fork.
 
 ==== Consensus Software Development