Edited 16_security_privacy_ln.asciidoc with Atlas code editor

16_security_privacy_ln.asciidoc

@@ -535,7 +535,7 @@ We're still in the early stages of the Lightning Network.
 Many of the concerns listed in this chapter are likely to be addressed as it matures and grows.
 In the meantime, there are some measures that you can take to guard your node against malicious users; something as simple as updating the default parameters that your node runs with can go a long way in hardening your node.
 
-== Unannounced channels
+=== Unannounced channels
 
 If you intend to use the Lightning Network to send and receive funds between nodes and wallets you control, and have no interest in routing other users' payments, there is little need to announce your channels to the rest of the network.
 You could open a channel between, say, your desktop PC running a full node and your mobile phone running a Lightning Wallet and simply forgo the channel announcement discussed in <<ch03_How_Lightning_Works>>.
@@ -560,6 +560,7 @@ However, since the opening and commitment transactions are pseudonymous it will
 In addition, the Taproot update of 2021 makes it difficult to distinguish between channel opening and closing transactions and other specific kinds of Bitcoin transactions.
 Hence, while unannouned channels are not completely private, they do provide some privacy benefits when used carefully.
 
+[[routing_considerations]]
 === Routing considerations
 
 As covered in the <<denial_of_service>> section, nodes that open public channels expose themselves to the risk of a series of attacks on their channels.
@@ -597,7 +598,7 @@ Some potential strategies are:
 * No risk: do not accept any incoming channels.
 * Low risk: accept channels from a known set of nodes that you have previously had successful channels open with
 * Medium risk: only accept channels from nodes that have been present in the graph for a longer period, and have some long-lived channels.
-* Higher risk: accept any incoming channels, and implement the mitigations described in the <<routing_considerations>> chapter.
+* Higher risk: accept any incoming channels, and implement the mitigations described in <<routing_considerations>>.
 
 === Conclusion
 In summary, privacy and security are nuanced, complex topics and while many researchers and developers are looking for network-wide improvements, it's important for everyone participating in the network to understand what they can do to protect their own privacy and increase security on an individual node level.