X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=lightning%2Fsrc%2Fchain%2Fchannelmonitor.rs;h=28b6da4722a7b4e3820541b30c89047d1e8e5cfe;hb=refs%2Fheads%2F2021-03-check-tx;hp=c2c791c4b172b8335c43117ff191e93320c3cddc;hpb=2cb655b3b188e521028817bf2506b5a99f9071e7;p=rust-lightning

diff --git a/lightning/src/chain/channelmonitor.rs b/lightning/src/chain/channelmonitor.rs
index c2c791c4..28b6da47 100644
--- a/lightning/src/chain/channelmonitor.rs
+++ b/lightning/src/chain/channelmonitor.rs
@@ -19,8 +19,6 @@
 //! ChannelMonitors should do so). Thus, if you're building rust-lightning into an HSM or other
 //! security-domain-separated system design, you should consider having multiple paths for
 //! ChannelMonitors to get out of the HSM and onto monitoring devices.
-//!
-//! [`chain::Watch`]: ../trait.Watch.html
 
 use bitcoin::blockdata::block::{Block, BlockHeader};
 use bitcoin::blockdata::transaction::{TxOut,Transaction};
@@ -75,8 +73,6 @@ pub struct ChannelMonitorUpdate {
 	/// The only instance where update_id values are not strictly increasing is the case where we
 	/// allow post-force-close updates with a special update ID of [`CLOSED_CHANNEL_UPDATE_ID`]. See
 	/// its docs for more details.
-	///
-	/// [`CLOSED_CHANNEL_UPDATE_ID`]: constant.CLOSED_CHANNEL_UPDATE_ID.html
 	pub update_id: u64,
 }
 
@@ -193,8 +189,6 @@ pub enum MonitorEvent {
 /// Simple structure sent back by `chain::Watch` when an HTLC from a forward channel is detected on
 /// chain. Used to update the corresponding HTLC in the backward channel. Failing to pass the
 /// preimage claim backward will lead to loss of funds.
-///
-/// [`chain::Watch`]: ../trait.Watch.html
 #[derive(Clone, PartialEq)]
 pub struct HTLCUpdate {
 	pub(crate) payment_hash: PaymentHash,
@@ -1187,8 +1181,6 @@ impl<Signer: Sign> ChannelMonitor<Signer> {
 
 	/// Get the list of HTLCs who's status has been updated on chain. This should be called by
 	/// ChannelManager via [`chain::Watch::release_pending_monitor_events`].
-	///
-	/// [`chain::Watch::release_pending_monitor_events`]: ../trait.Watch.html#tymethod.release_pending_monitor_events
 	pub fn get_and_clear_pending_monitor_events(&self) -> Vec<MonitorEvent> {
 		self.inner.lock().unwrap().get_and_clear_pending_monitor_events()
 	}
@@ -1509,8 +1501,13 @@ impl<Signer: Sign> ChannelMonitorImpl<Signer> {
 					self.lockdown_from_offchain = true;
 					if *should_broadcast {
 						self.broadcast_latest_holder_commitment_txn(broadcaster, logger);
-					} else {
+					} else if !self.holder_tx_signed {
 						log_error!(logger, "You have a toxic holder commitment transaction avaible in channel monitor, read comment in ChannelMonitor::get_latest_holder_commitment_txn to be informed of manual action to take");
+					} else {
+						// If we generated a MonitorEvent::CommitmentTxBroadcasted, the ChannelManager
+						// will still give us a ChannelForceClosed event with !should_broadcast, but we
+						// shouldn't print the scary warning above.
+						log_info!(logger, "Channel off-chain state closed after we broadcasted our latest commitment transaction.");
 					}
 				}
 			}
@@ -2450,11 +2447,8 @@ pub trait Persist<ChannelSigner: Sign>: Send + Sync {
 	/// stored channel data). Note that you **must** persist every new monitor to
 	/// disk. See the `Persist` trait documentation for more details.
 	///
-	/// See [`ChannelMonitor::serialize_for_disk`] for writing out a `ChannelMonitor`,
+	/// See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`,
 	/// and [`ChannelMonitorUpdateErr`] for requirements when returning errors.
-	///
-	/// [`ChannelMonitor::serialize_for_disk`]: struct.ChannelMonitor.html#method.serialize_for_disk
-	/// [`ChannelMonitorUpdateErr`]: enum.ChannelMonitorUpdateErr.html
 	fn persist_new_channel(&self, id: OutPoint, data: &ChannelMonitor<ChannelSigner>) -> Result<(), ChannelMonitorUpdateErr>;
 
 	/// Update one channel's data. The provided `ChannelMonitor` has already
@@ -2476,14 +2470,9 @@ pub trait Persist<ChannelSigner: Sign>: Send + Sync {
 	/// them in batches. The size of each monitor grows `O(number of state updates)`
 	/// whereas updates are small and `O(1)`.
 	///
-	/// See [`ChannelMonitor::serialize_for_disk`] for writing out a `ChannelMonitor`,
+	/// See [`ChannelMonitor::write`] for writing out a `ChannelMonitor`,
 	/// [`ChannelMonitorUpdate::write`] for writing out an update, and
 	/// [`ChannelMonitorUpdateErr`] for requirements when returning errors.
-	///
-	/// [`ChannelMonitor::update_monitor`]: struct.ChannelMonitor.html#impl-1
-	/// [`ChannelMonitor::serialize_for_disk`]: struct.ChannelMonitor.html#method.serialize_for_disk
-	/// [`ChannelMonitorUpdate::write`]: struct.ChannelMonitorUpdate.html#method.write
-	/// [`ChannelMonitorUpdateErr`]: enum.ChannelMonitorUpdateErr.html
 	fn update_persisted_channel(&self, id: OutPoint, update: &ChannelMonitorUpdate, data: &ChannelMonitor<ChannelSigner>) -> Result<(), ChannelMonitorUpdateErr>;
 }