diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc
index e30594e4..ac05481c 100644
--- a/ch08_signatures.adoc
+++ b/ch08_signatures.adoc
@@ -652,7 +652,7 @@ cases.  More complex schemes have been proposed that address these
 shortcomings.
 
 In addition to the key cancellation attack, there are a number of
-attacks possible against nonces.  Recall that the purpose of the nonce
+attacks possible against ((("nonce attacks")))nonces.  Recall that the purpose of the nonce
 is to prevent anyone from being able to use their knowledge of other values
 in the signature verification equation to solve for your private key,
 determining its value.  To effectively accomplish that, you must use a
@@ -666,13 +666,13 @@ there's no single multisignature protocol to recommend in all cases.
 Instead, we'll note three from the MuSig family of protocols:
 
 MuSig::
-  Also called _MuSig1_, this protocol requires three rounds of
+  Also called _MuSig1_, this protocol((("MuSig protocol"))) requires three rounds of
   communication during the signing process, making it similar to the
   process we just described.  MuSig1's greatest advantage is its
   simplicity.
 
 MuSig2::
-  This only requires two rounds of communication and can sometimes allow
+  This only ((("MuSig2 protocol")))requires two rounds of communication and can sometimes allow
   one of the rounds to be combined with key exchange.  This can
   significantly speed up signing for certain protocols, such as how
   scriptless multisignatures are planned to be used in the Lightning
@@ -680,7 +680,7 @@ MuSig2::
   multisignature protocol that has a BIP as of this writing).
 
 MuSig-DN::
-  DN stands for Deterministic Nonce, which eliminates as a concern a
+  DN stands ((("MuSig-DN protocol")))((("repeated session attack")))for Deterministic Nonce, which eliminates as a concern a
   problem known as the _repeated session attack_.  It can't be combined
   with key exchange and it's significantly more complex to implement
   than MuSig or MuSig2.