f - Fix ChainMonitor::update_best_block docs

Author: jkczyz

lightning/src/chain/chainmonitor.rs

@@ -116,12 +116,14 @@ where C::Target: chain::Filter,
 	/// block.
 	///
 	/// Must be called after new blocks become available for the most recent block. Intermediary
-	/// blocks, however, may be safely skipped. For a chain reorganization, this must be called at
-	/// least at the fork point and then again for the most recent block; intermediary blocks may be
-	/// skipped as before.
+	/// blocks, however, may be safely skipped. For a chain reorganization, must either be:
+	/// * called at at the fork point and then again for the most recent block -- intermediary
+	///   blocks may be skipped as before -- or
+	/// * not called in favor of calling [`transaction_unconfirmed`] for any affected transactions.
 	///
 	/// [`block_connected`]: Self::block_connected
 	/// [`transactions_confirmed`]: Self::transactions_confirmed
+	/// [`transaction_unconfirmed`]: Self::transaction_unconfirmed
 	pub fn update_best_block(&self, header: &BlockHeader, height: u32) {
 		self.process_transactions(header, &[], |monitor, txdata| {
 			// Recursive calls can supply txdata when chain::Filter::register_output returns a