Module lightning::ln::channelmonitor

The logic to monitor for on-chain transactions and create the relevant claim responses lives here.

ChannelMonitor objects are generated by ChannelManager in response to relevant messages/actions, and MUST be persisted to disk (and, preferably, remotely) before progress can be made in responding to certain messages, see ManyChannelMonitor for more.

Note that ChannelMonitors are an important part of the lightning trust model and a copy of the latest ChannelMonitor must always be actively monitoring for chain updates (and no out-of-date 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.

Structs

ChannelMonitor	A ChannelMonitor handles chain events (blocks connected and disconnected) and generates on-chain transactions to ensure no loss of funds occurs.
ClaimTxBumpMaterial	Higher-level cache structure needed to re-generate bumped claim txn if needed
HTLCUpdate	Simple structure send back by ManyChannelMonitor in case of HTLC detected onchain from a forward channel and from which info are needed to update HTLC in a backward channel.
MonitorUpdateError	General Err type for ChannelMonitor actions. Generally, this implies that the data provided is inconsistent with the ChannelMonitor being called. eg for ChannelMonitor::insert_combine this means you tried to merge two monitors for different channels or for a channel which was restored from a backup and then generated new commitment updates. Contains a human-readable error message.
SimpleManyChannelMonitor	A simple implementation of a ManyChannelMonitor and ChainListener. Can be used to create a watchtower or watch our own channels.

Enums

ChannelMonitorUpdateErr

An error enum representing a failure to persist a channel monitor update.

Traits

ManyChannelMonitor

Simple trait indicating ability to track a set of ChannelMonitors and multiplex events between them. Generally should be implemented by keeping a local SimpleManyChannelMonitor and passing events to it, while also taking any add_update_monitor events and passing them to some remote server(s).