f - fix grammar nits

Author: jkczyz

docs/blockdata.md

@@ -34,9 +34,9 @@ We will walk through this process as depicted here:
 
 ## Block Source
 
-Initially, our node doesn't have any channels and so has no data to monitor for
-on-chain. When a channel is opened with a peer, the `ChannelManager` creates a
-`ChannelMonitor` and passes it to the `ChainMonitor` to watch.
+Initially, our node doesn't have any channels and hence has no data to monitor
+for on-chain. When a channel is opened with a peer, the `ChannelManager` creates
+ a `ChannelMonitor` and passes it to the `ChainMonitor` to watch.
 
 At this point, LDK needs to be fed chain data of interest so that it can respond
 accordingly. It supports receiving either full blocks or pre-filtered blocks.
@@ -122,8 +122,8 @@ later. For now, let's look at the more interesting case of pre-filtered blocks.
 
 For environments that are resource constrained, receiving and processing all
 transaction data may not be feasible. LDK handles this case by signaling back
-with which transactions and outputs it is interested in. This information can
-then be used to filter blocks prior to sending them to your node.
+which transactions and outputs it is interested in. This information can then be
+used to filter blocks prior to sending them to your node.
 
 For example, if your block source is an Electrum client, you can pass along this
 information to it. Or if you are making use of a BIP 157 client, you can check