Update blockchain_data guide

docs/blockchain_data/chain_activity.md

@@ -6,7 +6,7 @@ a `ChannelMonitor` and passes it to the `ChainMonitor` to watch.
 
 At this point, you need to feed LDK any chain data of interest so that it can
 respond accordingly. It supports receiving either full blocks or pre-filtered
-blocks using the `chain::Listen` interface. While block data can sourced from
+blocks using the `chain::Listen` interface. While block data can be sourced from
 anywhere, it is your responsibility to call the `block_connected` and
 `block_disconnected` methods on `ChannelManager` and `ChainMonitor`. This allows
 them to update channel state and respond to on-chain events, respectively.
@@ -24,4 +24,4 @@ the `BlockSource` interface or use one of the samples that it provides.
 
 ::: tip Note
 Currently, `lightning-block-sync` is only available in Rust.
-:::
+:::

docs/blockchain_data/confirmed_transactions.md

@@ -6,7 +6,7 @@ provide a block-centric interface, like Electrum?
 
 LDK has a `chain::Confirm` interface to support this use case, analogous to the
 block-oriented `chain::Listen` interface which we've been using up until now.
-With this alternative approach, you still need to give LDK block headers but
+With this alternative approach, you still need to give LDK block headers, but
 only for blocks containing transactions of interest. These are identified by
 `chain::Filter` as before. You also need to notify LDK of any transactions with
 insufficient confirmation that have been reorganized out of the chain. Use the
@@ -20,4 +20,4 @@ this interface is intended to be used.
 Be advised that `chain::Confirm` is a less mature interface than
 `chain::Listen`. As such, there is not yet a utility like `lightning-block-sync`
 to use for interacting with clients like Electrum.
-:::
+:::

docs/blockchain_data/full_blocks.md

@@ -5,10 +5,10 @@ straight forward: call the appropriate methods on `ChannelManager` and
 `ChainMonitor` as blocks are connected and disconnected. LDK will handle the
 rest!
 
-So what happens? The `ChannelManager` examines the blocks transactions and
+So what happens? The `ChannelManager` examines the block's transactions and
 updates the internal channel state as needed. The `ChainMonitor` will detect
 any spends of the channel funding transaction or any pertinent transaction
 outputs, tracking them as necessary.
 
 If necessary, LDK will broadcast a transaction on your behalf. More on that
-later. For now, let's look at the more interesting case of pre-filtered blocks.
+later. For now, let's look at the more interesting case of pre-filtered blocks.

docs/blockchain_data/pre_filtered_blocks.md

@@ -6,7 +6,7 @@ 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
+information to it. Or, if you are making use of a BIP 157 client, you can check
 if a block contains relevant transactions before fetching it.
 
 So how does this work in practice? `ChainMonitor` is parameterized by an