My final edits on these BOLT-7 changes

Author: Shannon Appelcline

07-routing-gossip.md

@@ -15,9 +15,22 @@ one valid `channel_announcement` for any channel, but at least two
 `channel_update` messages are expected.
 
 To support node discovery, peers exchange `node_announcement`
-messages, which supply additional information about nodes There can be
+messages, which supply additional information about nodes. There can be
 multiple `node_announcement` messages, to update node information.
 
+# Table of Contents
+
+  * [The `announcement_signatures` Message](#the-announcement_signatures-message)
+  * [The `channel_announcement` Message](#the-channel_announcement-message)
+  * [The `node_announcement` Message](#the-node_announcement-message)
+  * [The `channel_update` Message](#the-channel_update-message)
+  * [Initial Sync](#initial-sync)
+  * [Rebroadcasting](#rebroadcasting)
+  * [HTLC Fees](#htlc-fees)
+  * [Pruning the Network View](#pruning-the-network-view)
+  * [Recommendations for Routing](#recommendations-for-routing)
+  * [References](#references)
+
 ## The `announcement_signatures` Message
 
 This is a direct message between two endpoints of a channel and serves as an opt-in mechanism to allow the announcement of the channel to the rest of the network.
@@ -34,17 +47,17 @@ The willingness of the initiating node to announce the channel is signaled durin
 
 ### Requirements
 
-The `announcement_signatures` message is created by constructing a `channel_announcement` message corresponding to the newly established channel and signing it with the secrets matching an endpoint's `node_id` and `bitcoin_key`. The message is then sent using an `announcement_signatures`.
+The `announcement_signatures` message is created by constructing a `channel_announcement` message, corresponding to the newly established channel, and signing it with the secrets matching an endpoint's `node_id` and `bitcoin_key`. The message is then sent using an `announcement_signatures`.
 
 The `short_channel_id` is the unique description of the funding transaction.
 It is constructed with the most significant 3 bytes indicating the block
 height, the next 3 bytes indicating the transaction index within the
 block, and the least significant two bytes indicating the output
 index that pays to the channel.
 
-If the `open_channel` message had the `announce_channel` bit set, then both nodes must send the `announcement_signatures` message, otherwise they MUST NOT.
+If the `open_channel` message had the `announce_channel` bit set, then both nodes MUST send the `announcement_signatures` message, otherwise they MUST NOT.
 
-If sent, `announcement_signatures` messages MUST NOT be sent until `funding_locked` has been sent and the funding transaction has at least 6 confirmations.
+If sent, `announcement_signatures` messages MUST NOT be sent until `funding_locked` has been sent and the funding transaction has at least six confirmations.
 
 The recipient MAY fail the channel if the `node_signature` or `bitcoin_signature` is incorrect.
 The recipient SHOULD queue the `channel_announcement` message for its peers if it has sent and received a valid `announcement_signatures` message.
@@ -61,10 +74,10 @@ its fee levels and expiry using `channel_update`.
 Proving the existence of a channel between `node_1` and
 `node_2` requires:
 
-1. Proving that the funding transaction pays to `bitcoin_key_1` and
-   `bitcoin_key_2`.
-2. Proving that `node_1` owns `bitcoin_key_1`
-3. Proving that `node_2` owns `bitcoin_key_2`
+1. proving that the funding transaction pays to `bitcoin_key_1` and
+   `bitcoin_key_2`
+2. proving that `node_1` owns `bitcoin_key_1`
+3. proving that `node_2` owns `bitcoin_key_2`
 
 The first proof is accomplished by assuming that all nodes know the unspent
 transaction outputs, and thus can find the output given by
@@ -77,7 +90,7 @@ and `bitcoin_signature_2`, generated by each `bitcoin_key` and signing
 the corresponding `node_id`).
 
 It is also necessary to prove that `node_1` and `node_2` both agree on this
-announcement message; that is accomplished by having a signature from each
+announcement message; this is accomplished by having a signature from each
 `node_id` signing the message (`node_signature_1` and
 `node_signature_2`).
 
@@ -177,7 +190,7 @@ optional) ones will have odd feature bits, incompatible ones will have
 even feature bits (["It's OK to be odd!"](00-introduction.md#glossary-and-terminology-guide)).
 Incompatible features will result in the announcement not being forwarded by nodes that don't understand them.
 
-## The `node_announcement` message
+## The `node_announcement` Message
 
 This allows a node to indicate extra data associated with it, in
 addition to its public key. To avoid trivial denial of service attacks,
@@ -286,12 +299,12 @@ to be ordered in ascending order, unknown ones can be safely ignored.
 Future fields beyond `addresses` can still be added, optionally with
 padding within `addresses` if they require certain alignment.
 
-## The `channel_update` message
+## The `channel_update` Message
 
 After a channel has been initially announced, each side independently
 announces the fees and minimum expiry delta it requires to relay HTLCs
-through this channel. They use the 8-byte
-channel shortid that matches the `channel_announcement` and one bit
+through this channel. Each uses the 8-byte
+channel shortid that matches the `channel_announcement` and 1 bit
 in the `flags` field
 to indicate which end this is. A node can do this multiple times, if
 it wants to change fees.