index fixes

ch02_overview.adoc

@@ -621,7 +621,7 @@ look like <<block-alice2>>.
 .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
+In this chapter, we((("transactions", "spending bitcoins", startref="transaction-spend2"))) saw how transactions build a chain that moves value
 from owner to owner. We also tracked Alice's transaction from the
 moment it was created in her wallet, through the Bitcoin network, and to
 the miners who recorded it on the blockchain. In the rest of this book,

ch04_keys.adoc

@@ -1836,7 +1836,7 @@ gives discount pricing to Eugenia.
 // https://github.com/MakisChristou/vanitybech
 
 We don't expect to see many vanity addresses in
-the future unless the preceding problems ((("public key cryptography", "vanity addresses", startref="pub-key-vanity")))((("vanity addresses", startref="vanity-addr")))((("privacy", "vanity addresses", startref="privacy-vanity")))((("addresses", "vanity", startref="address-vanity")))are solved.
+the future unless the preceding problems are solved.
 
 [[paper_wallets]]
 ==== Paper Wallets

ch06_transactions.adoc

@@ -136,7 +136,7 @@ If you implement a protocol that uses presigned transactions, ensure
 that it doesn't use any features that are reserved for future upgrades.
 Bitcoin Core's default transaction relay policy does not allow the use
 of reserved features.  You can test whether a transaction complies with
-that policy by using Bitcoin Core's +testmempoolaccept+ RPC on ((("transactions", "presigned", startref="transaction-presign")))((("presigned transactions", startref="presign-transaction")))Bitcoin
+that policy by using Bitcoin Core's +testmempoolaccept+ RPC on Bitcoin
 mainnet.
 ****
 
@@ -811,7 +811,7 @@ txid for Tx~0~ is part of the input's outpoint in Tx~1~.  That means
 there's no way for Alice and Bob to construct Tx~1~ until both
 signatures for Tx~0~ are known--but if they know the signatures for
 Tx~0~, one of them can broadcast that transaction before signing the
-refund transaction, eliminating the guarantee of a refund.  This((("transactions", "witnesses", "circular dependencies", startref="transaction-witness-circular")))((("witnesses", "circular dependencies", startref="witness-circular")))((("circular dependencies", startref="circular"))) is a
+refund transaction, eliminating the guarantee of a refund.  This is a
 _circular dependency_.
 
 ==== Third-Party Transaction Malleability

ch09_fees.adoc

@@ -193,7 +193,7 @@ rate and it will be confirmed earlier than expected.  There's no way to
 lower the fee rate on a transaction you've already sent, so you're stuck
 paying a higher fee rate.  But, when fee rates go up, there's a need for
 methods to be able to increase the fee rates on those transactions,
-which is called _fee bumping_.  There are two commonly used types of((("transaction fees", "fee rates", startref="fees-rates")))((("fee rates", startref="fee-rate")))((("estimating fee rates", startref="estimate-fee-rate"))) fee
+which is called _fee bumping_.  There are two commonly used types of fee
 bumping in Bitcoin, replace by fee (RBF) and child pays for parent
 (CPFP).
 
@@ -681,5 +681,5 @@ other uses of the lock time field.
 As Bitcoin continues to mature, and as the subsidy continues to decline,
 fees become more and more important to Bitcoin users, both in their
 day-to-day use for getting transactions confirmed quickly and in
-providing an incentive for miners to continue securing((("transaction fees", "fee sniping", startref="transaction-fee-sniping")))((("fee sniping", startref="fee-snipe")))((("timelocks", "fee sniping and", startref="timelock-fee-snipe")))((("lock time", "fee sniping and", startref="lock-time-fee-snipe"))) Bitcoin
+providing an incentive for miners to continue securing((("timelocks", "fee sniping and", startref="timelock-fee-snipe")))((("lock time", "fee sniping and", startref="lock-time-fee-snipe"))) Bitcoin
 transactions with new proof of work.

ch12_mining.adoc

@@ -1070,7 +1070,7 @@ MTP changes the implementation of time calculations for
 lock time, +CLTV+, sequence, and +CSV+. The consensus time
 calculated by MTP is usually about one hour behind
 wall clock time. If you create timelock transactions, you should account
-for it when estimating the desired value to encode ((("decentralized consensus", "timestamps and", startref="decentral-consensus-timestamp")))((("consensus rules", "timestamps and", startref="consensus-timestamp")))((("timestamps", startref="timestamp")))((("median time past (MTP)", startref="median-time-past")))((("MTP (median time past)", startref="mtp-median")))((("mining", "timestamps", startref="mining-timestamps")))in lock time,
+for it when estimating the desired value to encode in lock time,
 sequence, +CLTV+, and +CSV+.
 
 === Successfully Mining the Block
@@ -1806,8 +1806,7 @@ blocks will now be mined every 50 minutes on average. The difficulty
 will not be adjusted for 2,016 blocks, which will take 100,800 minutes,
 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((("consensus rules", "hard forks", "difficulty and", startref="consensus-hard-fork-difficult")))((("forks", "hard forks", "difficulty and", startref="forks-hard-difficult")))((("hard forks", "difficulty and", startref="hard-forks-difficult")))((("difficulty", "hard forks and", startref="difficulty-hardfork")))
-transactions.
+of 5, as there are fewer blocks per hour available to record transactions.
 
 ==== Contentious Hard Forks