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

07_payment_channels.asciidoc

@@ -540,9 +540,9 @@ This is a conditional script (see <<conditional_scripts>>), which means the outp
 The first clause allows the output to be spent by anyone who can sign for +<revocationpubkey>+. A critical requirement to the security of this script is that the remote party *cannot* unilaterally sign with the `revocationpubkey`. To see why this is important, consider the scenario where the remote party breaches a previously revoked commitment, if they can sign with this key, then they can simply take the revocation clause _themselves_ and steal all the funds in the channel. Instead, we derive the `revocationpubkey` for _each_ state based on information from _both_ the self (local) and remote party. A clever use of symmetric and asymmetric cryptography is used to allow both sides to compute the `revocationpubkey` public key, but only the honest self party to compute the private key given their secret information.
 [TIP]
 ====
-As shown above, each side sends a `revocation_basepoint` during the initial channel negotiation messages as well as a `first_per_commitment_point`. The `revocation_basepoint` is static for the lifetime of the channel, while each new channel state will be based off a new `first_per_commitment_point`. 
+As shown above, each side sends a `revocation_basepoint` during the initial channel negotiation messages as well as a `first_per_commitment_point`. The `revocation_basepoint` is static for the lifetime of the channel, while each new channel state will be based off a new `first_per_commitment_point`.
 
-Given this information, the `revocationpubkey` for each channel state is derived via the following series of Elliptic Curve and hashing operations: `revocationpubkey = revocation_basepoint * sha256(revocation_basepoint || per_commitment_point) + per_commitment_point * sha256(per_commitment_point || revocation_basepoint)`. 
+Given this information, the `revocationpubkey` for each channel state is derived via the following series of Elliptic Curve and hashing operations: `revocationpubkey = revocation_basepoint * sha256(revocation_basepoint || per_commitment_point) + per_commitment_point * sha256(per_commitment_point || revocation_basepoint)`.
 
 Due to the commutative property of the Abelian groups that Elliptic Curves are defined over, once the `per_commitment_secret` (the private key for the `per_commitment_point`) is revealed by the remote party, self can derive the private key for the `revocationpubkey` with the following operation: `per_commitment_secret = (revocationbase_priv * sha256(revocationpubkey || per_commitment_point)) + (per_commitment_secret * sha256(per_commitment_point || revocation_basepoint)) mod N`.
 

08_routing_htlcs.asciidoc

@@ -51,7 +51,7 @@ Let's return to Alice who, in previous chapters, purchased a coffee from Bob wit
 Now Alice is watching a live stream from Dina, the gamer, and wants to send Dina a tip of 50,000 satoshis via the Lightning Network. But Alice has no direct channel with Dina. What can Alice do?
 
 Alice could open a direct channel with Dina, however that would require liquidity and on-chain fees which could be more than the value of the tip itself. Instead, Alice can use her existing open channels to send a tip to Dina _without_ the need to open a channel directly with Dina. This is possible, as long as there exists some path of channels from Alice to Dina with sufficient capacity to route the tip.
- 
+
 As you can see in <<routing_network>>, Alice has an open channel with Bob, the coffee shop owner. Bob, in turn, has an open channel with the software developer Chan who helps him with the point of sale system he uses in his coffee shop. Chan is also the owner of a large software company which develops the game that Dina plays, and they already have an open channel which Dina uses to pay for the game's license and in-game items.
 
 [[routing_network]]
@@ -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.
 
@@ -521,7 +521,7 @@ image::images/chan_onion_wrapping.png[]
 
 Alice starts with the 1300 onion payload created for Dina. The first 65 (or less) bytes of this are Dina's payload obfuscated and the rest is filler. Alice must be careful not to overwrite Dina's payload.
 
-Next, Alice needs to locate the ephemeral public key (that was generated at the very start for each hop) that will be prepended to the routing packet at this hop. 
+Next, Alice needs to locate the ephemeral public key (that was generated at the very start for each hop) that will be prepended to the routing packet at this hop.
 
 Remember that rather than include a unique ephemeral public key (that the sender and intermediate node use in an ECDH operation to arrive a shared secret), Sphinx uses a single ephemeral public key that is deterministically randomized at each hop.
 
@@ -548,7 +548,7 @@ image::images/bob_onion_wrapping.png[]
 
 Start with the onion payload (obfuscated) containing Chan's and Dina's hop payloads.
 
-Obtain the session key for this hop dervied from the blinding factor generated by the prior hop. 
+Obtain the session key for this hop dervied from the blinding factor generated by the prior hop.
 Include the prior hop's outer HMAC as this hop's inner HMAC.
 Insert Bob's hop payload at the beginning and shift everything else over to the right, dropping a Bob-hop-payload-size chunk from the end (it was filler anyway).
 
@@ -561,11 +561,11 @@ Calculate the outer HMAC and stick it on the end of Bob's hop payload.
 
 The final onion payload is ready to be sent to Bob. Alice doesn't need to add any more hop payloads.
 
-Alice calculates an HMAC for the onion payload, to cryptographically secure it with a checksum that Bob can verify. 
+Alice calculates an HMAC for the onion payload, to cryptographically secure it with a checksum that Bob can verify.
 
-Alice adds a 33-byte public session key that will be used by each hop to generate a shared-secret and the rho, mu, and pad keys. 
+Alice adds a 33-byte public session key that will be used by each hop to generate a shared-secret and the rho, mu, and pad keys.
 
-Finally Alice puts the onion version number (+0+ currently) in the front. 
+Finally Alice puts the onion version number (+0+ currently) in the front.
 
 This allows for future upgrades of the onion packet format.
 
@@ -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.