fixing xrefs

06_lightning_architecture.asciidoc

@@ -36,7 +36,7 @@ Here's what we will cover:
 
 <<payment_channels>>:: In this chapter we will look at how payment channels work, in significantly more depth than we saw in the earlier parts of the book. We will look at the structure and Bitcoin Script of the funding and commitment transactions and the process used by nodes to negotiate each step in the protocol.
 
-<<routing_htlcs>>:: Next, we will put together several payment channels in a network and route a payment from one end to the other. In that process we will dive into the Hash Time-Locked Contract smart contract and the Bitcoin Script that we use to construct it.
+<<routing>>:: Next, we will put together several payment channels in a network and route a payment from one end to the other. In that process we will dive into the Hash Time-Locked Contract smart contract and the Bitcoin Script that we use to construct it.
 
 <<channel_operation>>:: Putting together the concepts of a simple payment channel and a routed payment using HTLCs, we will now look at how HTLCs are part of each channel's commitment transaction. We will also look at the protocol for adding, settling, failing and removing HTLCs from the commitments.
 
@@ -46,10 +46,10 @@ Here's what we will cover:
 
 <<path_finding>>:: Next, we will see how the information from the gossip protocol is used by each node to build a "map" of the entire network, which it can use to find paths from one point to another to route payments. We'll also look at the exiting innovations in path finding such as multi-part payments.
 
-<<payment_requests>>:: A key part of the Lightning Network are payment requests, also known as Lighting Invoices. In this chapter we dissect the structure and encoding of an invoice.
+<<invoices>>:: A key part of the Lightning Network are payment requests, also known as Lighting Invoices. In this chapter we dissect the structure and encoding of an invoice.
 
 <<wire_protocol>>:: Underpinning the Lightning Network is the Peer-to-Peer protocol that nodes use to exchange messages about the network and about their channels. In this chapter we look at how those messages are constructed and the extension capabilities built into messages with feature bits and TLV encoding.
 
-<<encrypted_transport>>:: Moving down to the lower-level part of the network, we will look at the underlying encrypted transport system that ensures the secrecy and integrity of all communications between nodes.
+<<encrypted_message_transport>>:: Moving down to the lower-level part of the network, we will look at the underlying encrypted transport system that ensures the secrecy and integrity of all communications between nodes.
 
 Let's dive in!

08_routing_htlcs.asciidoc

@@ -1,6 +1,4 @@
-[[routing_on_a_network_of_payment_channels]]
 [[routing]]
-[[routing_htlcs]]
 == Routing on a Network of Payment channels
 
 In this chapter we will finally unpack how payment channels can be connected to form a _network of payment channels_ via a process called _routing_. Specifically, we will look at the first part of the routing layer, the Atomic & Trustless Multihop Payment protocol. This is highlighted by a double outline in the protocol suite, shown in <<LN_protocol_routing_highlight>>:

14_encrypted_transport.asciidoc

@@ -1,6 +1,4 @@
-[[brontide]]
 [[encrypted_message_transport]]
-[[encrypted_transport]]
 == Lightning's Encrypted Message Transport (Brontide)
 
 In this chapter we will review the Lightning Network's _Encrypted Message

15_payment_requests.asciidoc

@@ -1,6 +1,4 @@
 [[invoices]]
-[[lightning_payment_requests]]
-[[payment_requests]]
 == Lightning Payment Requests
 
 In this chapter we will look at _Lightning Payment Requests_ or as they are more commonly known _Lightning Invoices_.

16_security_privacy_ln.asciidoc

@@ -274,6 +274,7 @@ First, it is hard for an attacker to target unannounced channels.
 Second, nodes that implement just-in-time or JIT routing may be less prone to the attack.
 Finally, as multi-part payments make the problem of insufficient capacity less severe, the protocol developers may consider hiding some of the error details without harming efficiency.
 
+[[denial_of_service]]
 ==== Denial of service
 
 When resources are made publicly available, there is a risk that attackers may attempt to make that resource unavailable by executing a denial-of-service attack.

appendix_license_notices.asciidoc

@@ -37,4 +37,4 @@ SOFTWARE.
 
 === Lamassu Industries AG
 
-Images of the _Gaia_ Bitcoin ATM (https://lamassu.is/product/gaia) seen in [[bitcoin-atm]] are used with permission of Lamassu Industries AG. The use of these images is not an endorsement of the product or company, but are provided as a visual example of a Bitcoin ATM. 
+Images of the _Gaia_ Bitcoin ATM (https://lamassu.is/product/gaia) seen in <<bitcoin-atm>> are used with permission of Lamassu Industries AG. The use of these images is not an endorsement of the product or company, but are provided as a visual example of a Bitcoin ATM.