Made small grammar corrections to chapters 7, 8, 9, 10, and 11.

08_routing_htlcs.asciidoc

@@ -200,7 +200,7 @@ With a chain of contracts like this in place, Bob and Chan could not run away wi
 However, one issue still remains.
 If Dina refused to release her secret pre-image, then Chan, Bob, and Alice would all have their coins stuck in escrow but wouldn't be reimbursed.
 And similarly if anyone else along the chain failed to pass on the secret, the same thing would happen.
-So while no one can steal money from Alice everyone still have their money stuck in escrow permanently.
+So while no one can steal money from Alice, everyone would still have their money stuck in escrow permanently.
 
 Luckily, this can be resolved by adding a deadline to the contract.
 

09_channel_operation.asciidoc

@@ -326,7 +326,7 @@ At this point, you will easily understand why HTLCs are used for both "remote" a
 
 * Alice orders a coffee from Bob's shop page.
 * Bob's shop sends an invoice with a payment hash.
-* Alice constructs and HTLC from that payment hash.
+* Alice constructs an HTLC from that payment hash.
 * Alice offers the HTLC to Bob with +update_add_htlc+.
 * Alice and Bob exchange commitments and revocations adding the HTLC to their commitment transactions.
 * Bob sends +update_fulfill_htlc+ to Alice with the payment pre-image.

10_onion_routing.asciidoc

@@ -500,14 +500,14 @@ If a secret key is ever used again, then the node can detect it, and reject the
 
 The nature of HTLCs in the Lightning Network allows us to further strengthen the replay protection by adding an additional _economic_ incentive.
 Remember that the payment hash of an HTLC can only ever safely be used (for a complete payment) once.
-If a payment hash is used again, and traverses a node that has already seen the payment secret fo that hash, then they can simply pull the funds, and collect the entire payment amount without forwarding!
+If a payment hash is used again, and traverses a node that has already seen the payment secret for that hash, then they can simply pull the funds, and collect the entire payment amount without forwarding!
 We can use this fact to strengthen the replay protection by requiring that the _payment hash_ is included in our HMAC computation as the associated data.
 With this added step, attempting to replay an onion packet also requires the sender to commit to using the _same_ payment hash.
 As a result, on top of the normal replay protection, an attacker also stands to lose the entire amount of the HTLC replayed as well.
 
 One consideration with the ever-increasing set of session keys stored for replay protection is: are nodes able to reclaim this space?
 In the context of the Lightning Network, the answer is: yes!
-Once again, due to the uniquer attributes of the HTLC construct, we can make a further improvement over the base Sphinx protocol.
+Once again, due to the unique attributes of the HTLC construct, we can make a further improvement over the base Sphinx protocol.
 Given that HTLCs are _time locked_ contracts based on the absolute block height, once an HTLC has expired, then the contract is effectively permanently closed.
 As a result, nodes can use this CLTV expiration height as an indicator to know when it's safe to garbage collect an entry in the anti-replay log.
 
@@ -790,7 +790,7 @@ Finally the return node sends the return packet to the hop from which it receive
 
 Each hop receiving an error, will generate an +ammag+ key and obfuscate the return packet again using an XOR operation with the byte-stream from +ammag+.
 
-Eventually, the sender (origin node) receives a return packet. It will then generate +ammag+ and +um+ keys for each hop and XOR de-bfuscate the return error iteratively until it reveals the return packet.
+Eventually, the sender (origin node) receives a return packet. It will then generate +ammag+ and +um+ keys for each hop and XOR de-obfuscate the return error iteratively until it reveals the return packet.
 
 ==== Failure Messages
 

11_gossip_channel_graph.asciidoc

@@ -15,7 +15,7 @@ Thus, the sender has to be able to map the Lightning Network, by constructing a
 The channel graph is the interconnected set of publicly advertised channels, and the nodes that these channels interlink.
 
 As channels are backed by a funding transaction that is happening on-chain, one might falsely believe that Lightning Nodes could just extract the existing channels from the Bitcoin Blockchain.
-However this only possible to a certain extent.
+However this is only possible to a certain extent.
 The funding transactions are Pay-to-Witness-Script-Hash (P2WSH) addresses and the nature of the script (a 2-of-2 multisig) will only be revealed once the funding transaction output is spent.
 Even if the nature of the script was known it's important to remember that not all 2-of-2 multisig scripts correspond to payment channels.
 
@@ -222,7 +222,7 @@ The query option sub-domain scheme uses a series of key-value pairs where the ke
   * +r+: The "realm" byte which is used to determine which chain or realm    queries should be returned for. As is, the only value for this key is +0+ which denotes "Bitcoin".
 
   * +a+: Allows clients to filter out returned nodes based on the _types_ of addresses they advertise. As an example, this can be used to only obtain nodes that advertise a valid IPv6 address.
-      * The value that follows this type is based on a bitfled that _indexes_ into the set of specified address _type_ which are defined in BOLT 7. The default value for this field is +6+, which which represents both IPv4 and IPv6 (bits 1 and 2 are set)
+      * The value that follows this type is based on a bitfled that _indexes_ into the set of specified address _type_ which are defined in BOLT 7. The default value for this field is +6+, which represents both IPv4 and IPv6 (bits 1 and 2 are set)
 
   * +l+: A valid node public key serialized in compressed format. This allows a client to query for a specified node rather than receiving a set of random nodes.