f clarity

Author: TheBlueMatt

lightning/src/routing/network_graph.rs

@@ -434,12 +434,12 @@ where C::Target: chain::Access, L::Target: Logger
 		// message).
 		//
 		// Obnoxiously, `gossip_timestamp_filter` isn't *just* a filter, but its also a request for
-		// your peer to send you the full routing graph. Thus, in order to tell a peer to send you
-		// any updates as it sees them, you have to also ask for the full routing graph to be
-		// synced. If you set a timestamp filter near the current time, peers will simply not
-		// forward any new updates they see to you which were generated some time ago (which is
-		// not uncommon). If you instead set a timestamp filter near 0 (or two weeks ago), you will
-		// always get the full routing graph from all your peers.
+		// your peer to send you the full routing graph (subject to the filter). Thus, in order to
+		// tell a peer to send you any updates as it sees them, you have to also ask for the full
+		// routing graph to be synced. If you set a timestamp filter near the current time, peers
+		// will simply not forward any new updates they see to you which were generated some time
+		// ago (which is not uncommon). If you instead set a timestamp filter near 0 (or two weeks
+		// ago), you will always get the full routing graph from all your peers.
 		//
 		// Most lightning nodes today opt to simply turn off receiving gossip data which only
 		// propagated some time after it was generated, and, worse, often disable gossiping with