f - Clean up language and paragraph ordering

Author: jkczyz

docs/blockdata.md

@@ -113,7 +113,7 @@ rest!
 So what happens? The `ChannelManager` examines the blocks 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 of interest, tracking them as necessary.
+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.
@@ -129,8 +129,6 @@ 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
 if a block contains relevant transactions before fetching it.
 
-Either way, when a block is connected, its header must be processed by LDK.
-
 So how does this work in practice? `ChainMonitor` is parameterized by an
 optional type that implements `chain::Filter`:
 
@@ -179,6 +177,8 @@ When this is provided, `ChainMonitor` will call back to the filter as channels
 are opened and blocks connected. This gives the opportunity for the source to
 pre-filter blocks as desired.
 
+Regardless, when a block is connected, its header must be processed by LDK.
+
 ## Transaction Broadcast
 
 Inevitably, LDK will need to broadcast transactions on your behalf. As you