f clarify comment

Author: TheBlueMatt

lightning/src/ln/chanmon_update_fail_tests.rs

@@ -3107,10 +3107,10 @@ fn do_test_inverted_mon_completion_order(complete_bc_commitment_dance: bool) {
 	// channel, we immediately claim the HTLC on the upstream channel, before even doing a
 	// `commitment_signed` dance on the downstream channel. This implies that our
 	// `ChannelMonitorUpdate`s are generated in the right order - first we ensure we'll get our
-	// money, then we write the update that resolves giving money on the downstream node. This is
-	// safe as long as `ChannelMonitorUpdate`s complete in the order in which they are generated,
-	// but of course this may not be the case. For asynchronous update writes, we have to ensure
-	// monitor updates can block each other, preventing the inversion all together.
+	// money, then we write the update that resolves the downstream node claiming their money. This
+	// is safe as long as `ChannelMonitorUpdate`s complete in the order in which they are
+	// generated, but of course this may not be the case. For asynchronous update writes, we have
+	// to ensure monitor updates can block each other, preventing the inversion all together.
 	let chanmon_cfgs = create_chanmon_cfgs(3);
 	let node_cfgs = create_node_cfgs(3, &chanmon_cfgs);