/// increasing and increase by one for each new update, with one exception specified below.
///
/// This sequence number is also used to track up to which points updates which returned
- /// ChannelMonitorUpdateErr::TemporaryFailure have been applied to all copies of a given
+ /// [`ChannelMonitorUpdateStatus::InProgress`] have been applied to all copies of a given
/// ChannelMonitor when ChannelManager::channel_monitor_updated is called.
///
/// 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.
+ ///
+ /// [`ChannelMonitorUpdateStatus::InProgress`]: super::ChannelMonitorUpdateStatus::InProgress
pub update_id: u64,
}
CommitmentTxConfirmed(OutPoint),
/// Indicates a [`ChannelMonitor`] update has completed. See
- /// [`ChannelMonitorUpdateErr::TemporaryFailure`] for more information on how this is used.
+ /// [`ChannelMonitorUpdateStatus::InProgress`] for more information on how this is used.
///
- /// [`ChannelMonitorUpdateErr::TemporaryFailure`]: super::ChannelMonitorUpdateErr::TemporaryFailure
- UpdateCompleted {
+ /// [`ChannelMonitorUpdateStatus::InProgress`]: super::ChannelMonitorUpdateStatus::InProgress
+ Completed {
/// The funding outpoint of the [`ChannelMonitor`] that was updated
funding_txo: OutPoint,
/// The Update ID from [`ChannelMonitorUpdate::update_id`] which was applied or
},
/// Indicates a [`ChannelMonitor`] update has failed. See
- /// [`ChannelMonitorUpdateErr::PermanentFailure`] for more information on how this is used.
+ /// [`ChannelMonitorUpdateStatus::PermanentFailure`] for more information on how this is used.
///
- /// [`ChannelMonitorUpdateErr::PermanentFailure`]: super::ChannelMonitorUpdateErr::PermanentFailure
+ /// [`ChannelMonitorUpdateStatus::PermanentFailure`]: super::ChannelMonitorUpdateStatus::PermanentFailure
UpdateFailed(OutPoint),
}
impl_writeable_tlv_based_enum_upgradable!(MonitorEvent,
- // Note that UpdateCompleted and UpdateFailed are currently never serialized to disk as they are
+ // Note that Completed and UpdateFailed are currently never serialized to disk as they are
// generated only in ChainMonitor
- (0, UpdateCompleted) => {
+ (0, Completed) => {
(0, funding_txo, required),
(2, monitor_update_id, required),
},
}
/// Used by ChannelManager deserialization to broadcast the latest holder state if its copy of
- /// the Channel was out-of-date. You may use it to get a broadcastable holder toxic tx in case of
- /// fallen-behind, i.e when receiving a channel_reestablish with a proof that our counterparty side knows
- /// a higher revocation secret than the holder commitment number we are aware of. Broadcasting these
- /// transactions are UNSAFE, as they allow counterparty side to punish you. Nevertheless you may want to
- /// broadcast them if counterparty don't close channel with his higher commitment transaction after a
- /// substantial amount of time (a month or even a year) to get back funds. Best may be to contact
- /// out-of-band the other node operator to coordinate with him if option is available to you.
- /// In any-case, choice is up to the user.
+ /// the Channel was out-of-date.
+ ///
+ /// You may also use this to broadcast the latest local commitment transaction, either because
+ /// a monitor update failed with [`ChannelMonitorUpdateStatus::PermanentFailure`] or because we've
+ /// fallen behind (i.e. we've received proof that our counterparty side knows a revocation
+ /// secret we gave them that they shouldn't know).
+ ///
+ /// Broadcasting these transactions in the second case is UNSAFE, as they allow counterparty
+ /// side to punish you. Nevertheless you may want to broadcast them if counterparty doesn't
+ /// close channel with their commitment transaction after a substantial amount of time. Best
+ /// may be to contact the other node operator out-of-band to coordinate other options available
+ /// to you. In any-case, the choice is up to you.
+ ///
+ /// [`ChannelMonitorUpdateStatus::PermanentFailure`]: super::ChannelMonitorUpdateStatus::PermanentFailure
pub fn get_latest_holder_commitment_txn<L: Deref>(&self, logger: &L) -> Vec<Transaction>
where L::Target: Logger {
self.inner.lock().unwrap().get_latest_holder_commitment_txn(logger)
if *should_broadcast {
self.broadcast_latest_holder_commitment_txn(broadcaster, logger);
} 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");
+ log_error!(logger, "WARNING: You have a potentially-unsafe holder commitment transaction available to broadcast");
+ log_error!(logger, " in channel monitor for channel {}!", log_bytes!(self.funding_info.0.to_channel_id()));
+ log_error!(logger, " Read the docs for ChannelMonitor::get_latest_holder_commitment_txn and take manual action!");
} else {
// If we generated a MonitorEvent::CommitmentTxConfirmed, the ChannelManager
// will still give us a ChannelForceClosed event with !should_broadcast, but we
projects / rust-lightning / blobdiff