diff --git a/ch04_keys.adoc b/ch04_keys.adoc
index 43098ad0..c0deecd8 100644
--- a/ch04_keys.adoc
+++ b/ch04_keys.adoc
@@ -1019,7 +1019,7 @@ types of addresses to eliminate address collision attacks((("public key cryptogr
 
 === Bech32 Addresses
 
-In 2017, the ((("public key cryptography", "bech32 addresses", "advantages of", id="pub-key-bech32-adv")))((("bech32 addresses", "advantages of", id="bech32-adv")))Bitcoin protocol was upgraded.  When the upgrade is used,
+In 2017, the ((("public key cryptography", "bech32 addresses", "advantages of", id="pub-key-bech32-adv")))((("addresses", "bech32", "advantages of", id="address-bech32-adv")))((("bech32 addresses", "advantages of", id="bech32-adv")))Bitcoin protocol was upgraded.  When the upgrade is used,
 it prevents transaction
 identifiers (txids) from being changed without the consent of a spending
 user (or a quorum of signers when multiple signatures are required).
@@ -1124,11 +1124,11 @@ image::images/mbc3_0409.png["The same bech32 address QR encoded in lowercase and
   and have that wallet remain able to spend to bech32 addresses for
   users of new features added in future protocol upgrades.  It was
   hoped that we might never again need to go through the system-wide
-  upgrade cycles necessary to allow people to fully use P2SH and((("public key cryptography", "bech32 addresses", "advantages of", startref="pub-key-bech32-adv")))((("bech32 addresses", "advantages of", startref="bech32-adv")))((("segregated witness (segwit)", startref="segwit-bech32"))) segwit.
+  upgrade cycles necessary to allow people to fully use P2SH and((("public key cryptography", "bech32 addresses", "advantages of", startref="pub-key-bech32-adv")))((("addresses", "bech32", "advantages of", startref="address-bech32-adv")))((("bech32 addresses", "advantages of", startref="bech32-adv")))((("segregated witness (segwit)", startref="segwit-bech32"))) segwit.
 
 ==== Problems with Bech32 Addresses
 
-Bech32 addresses((("public key cryptography", "bech32 addresses", "problems with", id="pub-key-bech32-prob")))((("bech32 addresses", "problems with", id="bech32-prob"))) would have been a success in every area except for one
+Bech32 addresses((("public key cryptography", "bech32 addresses", "problems with", id="pub-key-bech32-prob")))((("addresses", "bech32", "problems with", id="address-bech32-prob")))((("bech32 addresses", "problems with", id="bech32-prob"))) would have been a success in every area except for one
 problem.  The mathematical guarantees about their ability to detect
 errors only apply if the length of the address you enter into a wallet
 is the same length of the original address.  If you add or remove any
@@ -1177,11 +1177,11 @@ or 62 characters long, so someone would need to add or remove the letter "q"
 from the penultimate position of a bech32 address 20 times in order to
 send money to an invalid address without a wallet being able to detect
 it.  However, it would become a problem for users in the future if
-a segwit-based upgrade were ever to be ((("public key cryptography", "bech32 addresses", "problems with", startref="pub-key-bech32-prob")))((("bech32 addresses", "problems with", startref="bech32-prob")))implemented.
+a segwit-based upgrade were ever to be ((("public key cryptography", "bech32 addresses", "problems with", startref="pub-key-bech32-prob")))((("addresses", "bech32", "problems with", startref="address-bech32-prob")))((("bech32 addresses", "problems with", startref="bech32-prob")))implemented.
 
 ==== Bech32m
 
-Although((("public key cryptography", "bech32 addresses", "bech32m", id="pub-key-bech32-bech32m")))((("bech32 addresses", "bech32m", id="bech32-bech32m")))((("bech32m addresses", id="bech32m"))) bech32 worked well for segwit v0, developers didn't want to
+Although((("public key cryptography", "bech32 addresses", "bech32m", id="pub-key-bech32-bech32m")))((("bech32 addresses", "bech32m", id="bech32-bech32m")))((("addresses", "bech32m", id="address-bech32m")))((("bech32m addresses", id="bech32m"))) bech32 worked well for segwit v0, developers didn't want to
 unnecessarily constrain output sizes in later versions of segwit.
 Without constraints, adding or removing a single "q" in a bech32 address
 could result in a user accidentally sending their money to an
@@ -1441,7 +1441,7 @@ recommend that you use the test vectors provided in BIP350.  We also ask
 that you ensure your code passes the test vectors related to paying future segwit
 versions that haven't been defined yet.  This will help make your
 software usable for many years to come even if you aren't able to add
-support for new Bitcoin features as soon as they become ((("public key cryptography", "bech32 addresses", "bech32m", startref="pub-key-bech32-bech32m")))((("bech32 addresses", "bech32m", startref="bech32-bech32m")))((("bech32m addresses", startref="bech32m")))((("encoding", "bech32m addresses", startref="encode-bech32m")))((("decoding", "bech32m addresses", startref="decode-bech32m")))available.
+support for new Bitcoin features as soon as they become ((("public key cryptography", "bech32 addresses", "bech32m", startref="pub-key-bech32-bech32m")))((("bech32 addresses", "bech32m", startref="bech32-bech32m")))((("addresses", "bech32m", startref="address-bech32m")))((("bech32m addresses", startref="bech32m")))((("encoding", "bech32m addresses", startref="encode-bech32m")))((("decoding", "bech32m addresses", startref="decode-bech32m")))available.
 
 [[priv_formats]]
 ==== Private Key Formats