Added missing XREFs in Chapter 3

03_how_ln_works.asciidoc

@@ -223,7 +223,7 @@ So, in our example, Bob holds a commitment transaction that pays Alice _immediat
 
 The two channel partners hold half of the revocation secret, so that neither one knows the whole secret. If they share their half, then the other channel partner has the full secret and can use it to exercise the revocation condition. When signing a new commitment transaction, each channel partner revokes the previous commitment by giving the other party their half of the revocation secret.
 
-We will examine the revocation mechanism in more detail in XREF HERE, where we will learn the details of how revocation secrets are constructed and used.
+We will examine the revocation mechanism in more detail in <<revocation>>, where we will learn the details of how revocation secrets are constructed and used.
 
 In simple terms, Alice signs Bob's new commitment transaction only if Bob offers his half of the revocation secret for the previous commitment. Bob only signs Alice's new commitment transaction if she gives him her half of the revocation secret from the previous commitment.
 
@@ -233,7 +233,7 @@ The timelock is set to a number of blocks up to 2016 (approximately two weeks).
 
 The timelock is adjustable and can be negotiated between channel partners. Usually, it is longer for larger capacity channels, and shorter for smaller channels, to align the incentives with the value of the funds.
 
-For every new update of the channel balance, new commitment transactions and new revocation secrets have to be created and saved. As long as a channel remains open, all revocation secrets _ever created_ for the channel need to be kept as they might be needed in the future. Fortunately, the secrets are rather small and it is only the channel partners who need to keep them, not the entire network. Furthermore, due to a smart derivation mechanism used to derive revocation secrets we only need to store the most recent secret, because previous secrets can be derived from it (See XREF HERE.)
+For every new update of the channel balance, new commitment transactions and new revocation secrets have to be created and saved. As long as a channel remains open, all revocation secrets _ever created_ for the channel need to be kept as they might be needed in the future. Fortunately, the secrets are rather small and it is only the channel partners who need to keep them, not the entire network. Furthermore, due to a smart derivation mechanism used to derive revocation secrets we only need to store the most recent secret, because previous secrets can be derived from it (See  <<revocation_secret_derivation>>.)
 
 Nevertheless, managing and storing the revocation secrets is one of the more elaborate parts of Lightning nodes that require node operators to maintain backups.
 
@@ -336,7 +336,7 @@ When publishing a commitment transaction during a force close, the on-chain fees
 
 [NOTE]
 ====
-Hash Time-Locked Contracts (HTLCs) will be covered in detail in XREF HERE.
+Hash Time-Locked Contracts (HTLCs) will be covered in detail in <<htlcs>>.
 For now, assume that these are payments that are routed across the Lightning Network, rather than payments made directly between the two channel partners.
 These HTLCs are carried as additional outputs in the commitment transactions, thereby increasing the transaction size and on-chain fees.
 ====
@@ -388,7 +388,7 @@ This software is either:
 
 Remember that the commitment transaction has a timeout period specified in a given number of blocks, up to a maximum of 2016 blocks.
 As long as you run your Lightning node once before the timeout period is reached, it will catch all cheating attempts.
-It is not advisable to take this kind of risk; it is important to keep a well maintained node running continuously (See XREF HERE).
+It is not advisable to take this kind of risk; it is important to keep a well maintained node running continuously (See <<continuous_operation>>).
 
 === Invoices
 
@@ -396,7 +396,7 @@ Most payments on the Lightning Network start with an invoice, generated by the r
 
 [NOTE]
 ====
-There is a way to send an "unsolicited" payment without an invoice, using a work-around in the protocol called _keysend_. We will examine this in XREF HERE.
+There is a way to send an "unsolicited" payment without an invoice, using a work-around in the protocol called _keysend_. We will examine this in  <<keysend>>.
 ====
 
 An invoice is a simple payment instruction containing information such as a unique payment identifier (called a payment hash), a recipient, an amount, and an optional text description.
@@ -568,7 +568,7 @@ The onion routing protocol used in Lightning has the following properties:
 
 . Errors can be sent back from the erring node to the original sender, using the same onion routed protocol. Error onions are indistinguishable from routing onions, to external observers and intermediary nodes. Error routing enables the trial-and-error "probing" method used to find a path that has sufficient capacity to successfully route a payment.
 
-Onion routing will be examined in detail in XREF HERE.
+Onion routing will be examined in detail in <<onion_routing>>.
 
 ==== Payment forwarding algorithm
 
@@ -638,7 +638,7 @@ The sender uses their Lightning wallet to pay the invoice, copying the invoice t
 
 There are some differences in the user experience however. A Bitcoin address is _reusable_. Bitcoin addresses never expire and if the owner of the address still holds the keys, the funds held within are always accessible. A sender can send any amount of bitcoin to a previously used address, and a recipient can post a single static address to receive many payments. While this goes against the best practices for privacy reasons, it is technically possible and in fact quite common.
 
-In Lightning however, each invoice can only be used once for a specific payment amount. You cannot pay more or less, you cannot use an invoice again and the invoice has an expiry time built in. In Lightning, a recipient has to generate a new invoice for each payment, specifying the payment amount in advance. There is an exception to this, a mechanism called _keysend_, which we will examine in XREF HERE.
+In Lightning however, each invoice can only be used once for a specific payment amount. You cannot pay more or less, you cannot use an invoice again and the invoice has an expiry time built in. In Lightning, a recipient has to generate a new invoice for each payment, specifying the payment amount in advance. There is an exception to this, a mechanism called _keysend_, which we will examine in <<keysend>>.
 
 ==== Selecting outputs vs. finding a path
 

05_node_operations.asciidoc

@@ -37,7 +37,7 @@ but somewhere else.
 
 There are many ways you can run a Lightning node ranging from a small mini-PC hosted in your home or a dedicated server to a hosted server in the cloud. The method you choose will depend on the resources you have and how much money you want to spend.
 
-
+[[continuous_operation]]
 ==== Why is reliability important for running a Lightning node?
 
 In Bitcoin, hardware is not particularly important unless one is specifically running a mining node.

07_payment_channels.asciidoc

@@ -624,6 +624,7 @@ The +revoke_and_ack+ message is defined in https://github.com/lightningnetwork/l
 +per_commitment_secret+:: Used to generate a revocation key for the previous (old) commitment, effectively revoking it.
 +next_per_commitment_point+:: Used to build a revocation_pubkey for the new commitment, so that it can later be revoked.
 
+[[revocation]]
 ==== Revoking and re-committing
 
 Let's look at this interaction between Alice and Bob more closely.