f grammar in changelog

Author: TheBlueMatt

CHANGELOG.md

@@ -8,15 +8,15 @@
  * `ConfirmationTarget` has been rewritten to provide information about the
    specific use LDK needs the feerate estimate for, rather than the generic
    low-, medium-, and high-priority estimates. This allows LDK users to more
-   accurately target their feerate estimates (#2660). For those wishint to
+   accurately target their feerate estimates (#2660). For those wishing to
    retain their existing behavior, see the table below for conversion.
  * `ChainHash` is now used in place of `BlockHash` where it represents the
    genesis block (#2662).
  * `lightning-invoice` payment utilities now take a `Deref` to
    `AChannelManager` (#2652).
  * `peel_onion` is provided to statelessly decode an `OnionMessage` (#2599).
  * `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (#2636, #2670)
- * `Display` is now implemented for `Outpoint` (#2649).
+ * `Display` is now implemented for `OutPoint` (#2649).
  * `Features::from_be_bytes` is now provided (#2640).
 
 For those moving to the new `ConfirmationTarget`, the new variants in terms of
@@ -41,10 +41,10 @@ the old mempool/low/medium/high priorities are as follows:
  * Anchor outputs are now properly considered when calculating the amount
    available to send in HTLCs. This can prevent force-closes in anchor channels
    when sending payments which overflow the available balance (#2674).
- * A peer which sends a `update_fulfill_htlc` message for a forwarded HTLC, then
-   reconnects prior to sending a `commitment_signed` (thus retransmitting their
-   `update_fulfill_htlc`) may result in the channel stalling and being unable
-   to make progress (#2661).
+ * A peer which sends an `update_fulfill_htlc` message for a forwarded HTLC,
+   then reconnects prior to sending a `commitment_signed` (thus retransmitting
+   their `update_fulfill_htlc`) may result in the channel stalling and being
+   unable to make progress (#2661).
  * In exceedingly rare circumstances, messages intended to be sent to a peer
    prior to reconnection can be sent after reconnection. This could result in
    undefined channel state and force-closes (#2663).