f jeff's grammar fixes

Author: TheBlueMatt

CHANGELOG.md

@@ -10,31 +10,31 @@
    `MessageSendEvent::PaymentFailureNetworkUpdate` but instead included in a
    new field in the `Event::PaymentFailed` events. Generally, this means route
    graph updates are no longer handled as a part of the `PeerManager` but
-   instead through the new `EventHandler` implementation of
+   instead through the new `EventHandler` implementation for
    `NetGraphMsgHandler`. To make this easy, a new parameter to
    `lightning-background-processor::BackgroundProcessor::start` is added, which
    contains an `Option`al `NetGraphmsgHandler`. If provided as `Some`, relevant
    events will be processed by the `NetGraphMsgHandler` prior to normal event
    handling (#1043).
  * `NetworkGraph` is now, itself, thread-safe. Accordingly, most functions now
    take `&self` instead of `&mut self` and the graph data can be accessed
-   through `NetworkGraph.read_only()` (#1043).
+   through `NetworkGraph.read_only` (#1043).
  * The balances available on-chain to claim after a channel has been closed are
    now exposed via `ChannelMonitor::get_claimable_balances` and
    `ChainMonitor::get_claimable_balances`. The second can be used to get
    information about all closed channels which still have on-chain balances
    associated with them. See enum variants of `ln::channelmonitor::Balance` and
    method documentation for the above methods for more information on the types
    of balances exposed (#1034).
- * When one HTLC out of several as a part of a multi-path payment fails, the
-   new field `all_paths_failed` in `Event::PaymentFailed` is set to `false`.
-   This implies that the payment has not failed, but only one part. Payment
-   resolution is only indicated by an `Event::PaymentSent` event or an
-   `Event::PaymentFailed` with `all_paths_failed` set to `true`, which is also
-   set for the last remaining part of a multi-path payment (#1053).
+ * When one HTLC of a multi-path payment fails, the new field `all_paths_failed`
+   in `Event::PaymentFailed` is set to `false`. This implies that the payment
+   has not failed, but only one part. Payment resolution is only indicated by an
+   `Event::PaymentSent` event or an `Event::PaymentFailed` with
+   `all_paths_failed` set to `true`, which is also set for the last remaining
+   part of a multi-path payment (#1053).
  * To better capture the context described above, `Event::PaymentFailed` has
    been renamed to `Event::PaymentPathFailed` (#1084).
- * A new event, `ChannelClosed` is provided by `ChannelManager` when a channel
+ * A new event, `ChannelClosed`, is provided by `ChannelManager` when a channel
    is closed, including a reason and error message (if relevant, #997).
  * `lightning-invoice` now considers invoices with sub-millisatoshi precision
    to be invalid, and requires millisatoshi values during construction (thus
@@ -50,7 +50,7 @@
 
 ## Bug Fixes
  * Fix a panic when reading a lightning invoice with a non-recoverable
-   signature. Further, restrict lightning invoice parsing require payment
+   signature. Further, restrict lightning invoice parsing to require payment
    secrets and better handle a few edge cases as required by BOLT 11 (#1057).
  * Fix a panic when receiving multiple messages (such as HTLC fulfill messages)
    after a call to `chain::Watch::update_channel` returned
@@ -73,14 +73,14 @@
    deserialized objects in 0.100. Such `Event`s will lead to an
    `Err(DecodeError::InvalidValue)` in versions prior to 0.0.100. The only such
    new event written by 0.0.101 is `Event::ChannelClosed` (#1087).
- * Payments which were initiated in versions prior to 0.0.101 may still
+ * Payments that were initiated in versions prior to 0.0.101 may still
    generate duplicate `PaymentSent` `Event`s or may have spurious values for
    `Event::PaymentPathFailed::all_paths_failed` (#1053).
  * The return values of `ChannelMonitor::get_claimable_balances` (and, thus,
    `ChainMonitor::get_claimable_balances`) may be spurious for channels where
    the spend of the funding transaction appeared on chain while running a
    version prior to 0.0.101. `Balance` information should only be relied upon
-   for channels which were closed while running 0.0.101+ (#1034).
+   for channels that were closed while running 0.0.101+ (#1034).
  * Payments failed while running versions prior to 0.0.101 will never have a
    `Some` for the `network_update` field (#1043).