- /// In order to broadcast the latest local commitment transaction, you'll need to call
- /// [`ChannelMonitor::get_latest_holder_commitment_txn`] and broadcast the resulting
- /// transactions once you've safely ensured no further channel updates can be generated by your
- /// [`ChannelManager`].
- ///
- /// Note that at least one final [`ChannelMonitorUpdate`] may still be provided, which must
- /// still be processed by a running [`ChannelMonitor`]. This final update will mark the
- /// [`ChannelMonitor`] as finalized, ensuring no further updates (e.g. revocation of the latest
- /// commitment transaction) are allowed.
- ///
- /// Note that even if you return a [`PermanentFailure`] due to unavailability of secondary
- /// [`ChannelMonitor`] copies, you should still make an attempt to store the update where
- /// possible to ensure you can claim HTLC outputs on the latest commitment transaction
- /// broadcasted later.
- ///
- /// In case of distributed watchtowers deployment, the new version must be written to disk, as
- /// state may have been stored but rejected due to a block forcing a commitment broadcast. This
- /// storage is used to claim outputs of rejected state confirmed onchain by another watchtower,
- /// lagging behind on block processing.
- ///
- /// [`PermanentFailure`]: ChannelMonitorUpdateStatus::PermanentFailure
- /// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager
- PermanentFailure,