CH06/07: Update titles, anchors, and cross-references links

chapters/authorization-authentication.adoc

@@ -268,7 +268,7 @@ contains a hash which commits to a public key.  P2PKH is best known as a
 the basis for a legacy Bitcoin address. An P2PKH output can be spent by
 presenting a public key which matches the hash commitment and a digital
 signature created by the corresponding private key (see
-<<digital_sigs>>).  Let's look at an example of a P2PKH scriptPubKey:
+<<c_signatures>>).  Let's look at an example of a P2PKH scriptPubKey:
 
 ----
 OP_DUP OP_HASH160 <Key Hash> OP_EQUALVERIFY OP_CHECKSIG
@@ -316,7 +316,7 @@ image::../images/mbc2_0605.png["Tx_Script_P2PubKeyHash_1"]
 image::../images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"]
 
 [[multisig]]
-=== Multisignature
+=== Scripted multisignatures
 
 ((("transactions", "advanced", "multisignature
 scripts")))((("transactions", "advanced", id="Tadv07")))((("scripting",
@@ -1847,7 +1847,8 @@ for its original purpose--in theory every payment could be using it,
 although we consider that unlikely.  However, P2C is widely used today
 in a slightly different form, which we'll see in <<taproot>>.
 
-=== Scriptless Multisignature
+[[scriptless_multisignatures_and_threshold_signatures]]
+=== Scriptless Multisignatures and Threshold Signatures
 
 In <<multisig>>, we looked at scripts which require signatures from
 multiple keys.  However, there's another way to require cooperation from

chapters/transactions.adoc

@@ -834,7 +834,7 @@ malleability_.
 ====
 There are cases when people want their transactions to be malleable and
 Bitcoin provides several features to support that, most notably the
-signature hashes (sighash) we'll learn about in <<sighashes>>.  For
+signature hashes (sighash) we'll learn about in <<sighash_types>>.  For
 example, Alice can use a sighash to allow Bob to help her pay some
 transaction fees.  This mutates Alice's transaction but only in a way
 that Alice wants.  For that reason, we will occasionally prefix the