Moved payment requests to chapter, renumbered

15_payment_requests.asciidoc

@@ -1,4 +1,3 @@
-[appendix]
 [[invoices]]
 [[lightning_payment_requests]]
 == Lightning Payment Requests
@@ -124,7 +123,6 @@ A full list of the currently defined multipliers is a follows:
 |==============================================
 
 
-
 ==== Bech32 & the Data Segment
 
 If the "unreadable" portion of looks familiar, then that's because it uses the
@@ -178,7 +176,7 @@ A full list of all the currently defined tagged fields is as follows:
 
 .BOLT 11 Tagged Invoice Fields
 [options="header"]
-|==================================================================================================================================================
+|===
 |Field Tag|Data Length|Usage
 |`p`|`52`|The `SHA-256` payment hash.
 |`s`|`52`|A `256-bit` secret that increase the end to end privacy of a payment by mitigating probing by intermediate nodes.
@@ -190,7 +188,7 @@ A full list of all the currently defined tagged fields is as follows:
 |`f`|Variable|A fall back on-chain address to be used to complete the payment if the payment cannot be completed over LN.
 |`r`|Variable|One or more entries that allow a receiver to give the sender additional ephemeral edges to complete the payment.
 `9`|Variable|A set of 5-bit values that contain the feature bits that are required in order to complete the payment.
-|==================================================================================================================================================
+|===
 
 The elements contained in the field `r` are commonly referred to as "routing
 hints". They allow the receiver to communicate an extra set of edges that may
@@ -212,3 +210,8 @@ payment. As an example, if a new payment type is added in the future that isn't
 backwards compatible with the original payment type, then the receiver can set
 a _required_ feature bit in order to communicate that the payer needs to
 underhand that feature in order to complete the payment.
+
+
+=== Conclusion
+
+As we have seen, invoices are a lot more than just a request for an amount. They contain critical information about _how_ to make the payment, such as "routing hints", the destination node's public key, ephemeral keys to increase security and much more. 

appendix_protocol_messages.asciidoc

@@ -1,14 +1,16 @@
 [appendix]
 [[wire_protocol_enumeration]]
-==== Wire Messages
+[[protocol_messages]]
+[[messages]]
+==== Wire Protocol Messages
 
-In this section, well outline the precise structure of each of the wire
-messages within the protocol. We'll do so in two parts: first we'll enumerate
+In this appendix, we outline the precise structure of each of the wire
+messages within the protocol. We do so in two parts: first we enumerate
 all the currently defined wire message types along with the message name
-corresponding to that type, we'll then double back and define the structure of
+corresponding to that type, we then define the structure of
 each of the wire messages (partitioned into logical groupings).
 
-First, we'll lead with an enumeration of all the currently defined types:
+First, we lead with an enumeration of all the currently defined types:
 
 .Message Types
 [options="header"]
@@ -75,7 +77,7 @@ we place a message into one of 8 (non exhaustive) buckets including:
 Notice how messages that belong to the same category typically share an
 adjacent _message type_ as well. This is done on purpose in order to group
 semantically similar messages together within the specification itself. With
-this roadmap laid out, we'll now visit each message category in order to define
+this roadmap laid out, we now visit each message category in order to define
 the precise structure and semantics of all defined messages within the LN
 protocol.