Small fixes to conclusion chapter

17_conclusion.asciidoc

@@ -23,7 +23,7 @@ Not only is Lightning advancing rapidly, but it is creating demand for new featu
 
 The Bitcoin system is, by necessity, a conservative system that has to preserve compatibility with consensus rules to avoid unplanned forks of the blockchain or partitions of the P2P network. As a result, new features require a lot of coordination and testing before they are implemented in "mainnet", the live production system.
 
-Here are some of the current or proposed innovations spurred by Lightning:
+Here are some of the current or proposed innovations in Bitcoin that are motivated by use cases in the Lightning Network:
 
 Neutrino:: A lightweight client protocol with improved privacy features over the legacy SPV protocol. Neutrino is mostly used by Lightning clients to access the Bitcoin blockchain.
 
@@ -39,7 +39,7 @@ Covenants:: Currently in the early stages of research, coventants allow transact
 
 The Lightning P2P protocol is highly extensible and has undergone a lot of change since its inception. The "It's OK to be odd" rule used in feature bits (see <<feature_bits>>) ensure that nodes can negotiate the features they support, enabling multiple independent upgrades to the protocol.
 
-===== Tlv extensibility
+===== TLV extensibility
 
 The Type-Length-Value (see <<tlv>>) mechanism for extending the messaging protocol is extremely powerful and has already enabled the introduction of several new capabilities in Lightning while maintaining both forward and backward compatibility.
 A prominent example that is currently being developed and makes use of this is path blinding and trampoline payments which allows a recipient to hide itself from the sender but also allows mobile clients to send payments without the necessity to store the full channel graph on their devices by using a third party to which they don't need to reveal the final recipient.
@@ -58,7 +58,7 @@ Large channels:: Large or "Wumbo" channels were introduced in a dynamic way to t
 
 Multi-Part Payments (MPP):: MPP was also introduced in an opt-in manner, but even better only requires the sender and recipient of a payment to be able to do MPP. The rest of the network simply routes HTLCs as if they are single-part payments.
 
-JIT-Routing:: An optional method that can be used by routing nodes to increase their reliability and to protect themsleves from being spammed.
+JIT-Routing:: An optional method that can be used by routing nodes to increase their reliability and to protect themselves from being spammed.
 
 Keysend:: An upgrade introduced independently by Lightning client implementations, it allows the sender to send money in an "unsolicited" and asynchronous way without requiring an invoice first.
 
@@ -72,7 +72,7 @@ Offers:: Currently Proposed as BOLT #12 but already implemented by some nodes th
 === Lightning Applications (LApps)
 
 While still in their infancy, we are already seeing the emergence of interesting Lightning Applications. Broadly defined as an application that uses the Lightning Protocol or a Lightning client as a component, LApps are the application layer of Lightning.
-A prominent example are LNURL that provides a similar functionality as BOLT #12 Offers but just over http and Lightning address that works on top of offers to provide users with an email style address to which others can send funds while the software in the background requests an invoice against the LNURL endpoint of the node. 
+A prominent example are LNURL that provides a similar functionality as BOLT #12 Offers but just over http and Lightning address that works on top of offers to provide users with an email style address to which others can send funds while the software in the background requests an invoice against the LNURL endpoint of the node.
 Further LApps are being built for simple games, messaging applications, micro-services, payable-APIs, paid dispensers (eg. fuel pumps), derivative trading systems, and much more.
 
 === Ready, Set, Go!