f - Remove ChannelManager docs that are repetitive with Confirm docs

Author: jkczyz

lightning/src/ln/channelmanager.rs

@@ -3394,21 +3394,6 @@ where
 {
 	/// Updates channel state to take note of transactions which were confirmed in the given block
 	/// at the given height.
-	///
-	/// Note that you must still call (or have called) [`best_block_updated`] with the block
-	/// information which is included here.
-	///
-	/// This method may be called before or after [`best_block_updated`] for a given block's
-	/// transaction data and may be called multiple times with additional transaction data for a
-	/// given block.
-	///
-	/// This method may be called for a previous block after a [`best_block_updated`] call has
-	/// been made for a later block, however it must *not* be called with transaction data from a
-	/// block which is no longer in the best chain (ie where [`best_block_updated`] has already
-	/// been informed about a blockchain reorganization which no longer includes the block which
-	/// corresponds to `header`).
-	///
-	/// [`best_block_updated`]: `Self::best_block_updated`
 	fn transactions_confirmed(&self, header: &BlockHeader, txdata: &TransactionData, height: u32) {
 		// Note that we MUST NOT end up calling methods on self.chain_monitor here - we're called
 		// during initialization prior to the chain_monitor being fully configured in some cases.
@@ -3421,19 +3406,7 @@ where
 		self.do_chain_event(Some(height), |channel| channel.transactions_confirmed(&block_hash, height, txdata, &self.logger).map(|a| (a, Vec::new())));
 	}
 
-	/// Updates channel state with the current best blockchain tip. You should attempt to call this
-	/// quickly after a new block becomes available, however if multiple new blocks become
-	/// available at the same time, only a single `best_block_updated()` call needs to be made.
-	///
-	/// This method should also be called immediately after any block disconnections, once at the
-	/// reorganization fork point, and once with the new chain tip. Calling this method at the
-	/// blockchain reorganization fork point ensures we learn when a funding transaction which was
-	/// previously confirmed is reorganized out of the blockchain, ensuring we do not continue to
-	/// accept payments which cannot be enforced on-chain.
-	///
-	/// In both the block-connection and block-disconnection case, this method may be called either
-	/// once per block connected or disconnected, or simply at the fork point and new tip(s),
-	/// skipping any intermediary blocks.
+	/// Updates channel state with the current best chain tip.
 	fn best_block_updated(&self, header: &BlockHeader, height: u32) {
 		// Note that we MUST NOT end up calling methods on self.chain_monitor here - we're called
 		// during initialization prior to the chain_monitor being fully configured in some cases.
@@ -3463,22 +3436,6 @@ where
 	}
 
 	/// Gets the set of txids which should be monitored for their confirmation state.
-	///
-	/// If you're providing information about reorganizations via [`transaction_unconfirmed`], this
-	/// is the set of transactions which you may need to call [`transaction_unconfirmed`] for.
-	///
-	/// This may be useful to poll to determine the set of transactions which must be registered
-	/// with an Electrum server or for which an Electrum server needs to be polled to determine
-	/// transaction confirmation state.
-	///
-	/// This may update after any [`transactions_confirmed`] or [`block_connected`] call.
-	///
-	/// Note that this is NOT the set of transactions which must be included in calls to
-	/// [`transactions_confirmed`] if they are confirmed, but a small subset of it.
-	///
-	/// [`transactions_confirmed`]: Self::transactions_confirmed
-	/// [`transaction_unconfirmed`]: Self::transaction_unconfirmed
-	/// [`block_connected`]: chain::Listen::block_connected
 	fn get_relevant_txids(&self) -> Vec<Txid> {
 		let channel_state = self.channel_state.lock().unwrap();
 		let mut res = Vec::with_capacity(channel_state.short_to_id.len());
@@ -3490,22 +3447,7 @@ where
 		res
 	}
 
-	/// Marks a transaction as having been reorganized out of the blockchain.
-	///
-	/// If a transaction is included in [`get_relevant_txids`], and is no longer in the main branch
-	/// of the blockchain, this function should be called to indicate that the transaction should
-	/// be considered reorganized out.
-	///
-	/// Once this is called, the given transaction will no longer appear on [`get_relevant_txids`],
-	/// though this may be called repeatedly for a given transaction without issue.
-	///
-	/// Note that if the transaction is confirmed on the main chain in a different block (indicated
-	/// via a call to [`transactions_confirmed`]), it may re-appear in [`get_relevant_txids`], thus
-	/// be very wary of race-conditions wherein the final state of a transaction indicated via
-	/// these APIs is not the same as its state on the blockchain.
-	///
-	/// [`transactions_confirmed`]: Self::transactions_confirmed
-	/// [`get_relevant_txids`]: Self::get_relevant_txids
+	/// Marks a transaction as having been reorganized out of the best chain.
 	fn transaction_unconfirmed(&self, txid: &Txid) {
 		let _persistence_guard = PersistenceNotifierGuard::new(&self.total_consistency_lock, &self.persistence_notifier);
 		self.do_chain_event(None, |channel| {