diff --git a/lightning/src/chain/channelmonitor.rs b/lightning/src/chain/channelmonitor.rs
index 0173e988082..810de80da95 100644
--- a/lightning/src/chain/channelmonitor.rs
+++ b/lightning/src/chain/channelmonitor.rs
@@ -4867,13 +4867,16 @@ impl<Signer: EcdsaChannelSigner> ChannelMonitorImpl<Signer> {
 		} else if let Some(per_commitment_claimable_data) = per_commitment_option {
 			assert_eq!(funding_spent.funding_txid(), funding_txid_spent);
 
-			// While this isn't useful yet, there is a potential race where if a counterparty
-			// revokes a state at the same time as the commitment transaction for that state is
-			// confirmed, and the watchtower receives the block before the user, the user could
-			// upload a new ChannelMonitor with the revocation secret but the watchtower has
-			// already processed the block, resulting in the counterparty_commitment_txn_on_chain entry
-			// not being generated by the above conditional. Thus, to be safe, we go ahead and
-			// insert it here.
+			// Track that this counterparty commitment tx appeared on-chain. This is
+			// used by `provide_payment_preimage` to look up the commitment number
+			// when a preimage arrives after the commitment tx is already confirmed.
+			// It also handles a race where a counterparty revokes a state at the
+			// same time as the commitment transaction for that state is confirmed,
+			// and the watchtower receives the block before the user. The user could
+			// upload a new ChannelMonitor with the revocation secret but the
+			// watchtower has already processed the block, resulting in the
+			// counterparty_commitment_txn_on_chain entry not being generated by
+			// the above conditional.
 			self.counterparty_commitment_txn_on_chain.insert(commitment_txid, commitment_number);
 
 			log_info!(logger, "Got broadcast of non-revoked counterparty commitment transaction {}", commitment_txid);