Module 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 chain::Watch 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.
• ChannelMonitorUpdate
  An update generated by the underlying channel itself which contains some new information the ChannelMonitor should be made aware of.
• HTLCUpdate
  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.

Enums

• Balance
  Details about the balance(s) available for spending once the channel appears on chain.
• MonitorEvent
  An event to be processed by the ChannelManager.

Constants

• ANTI_REORG_DELAY
  Number of blocks we wait on seeing a HTLC output being solved before we fail corresponding inbound HTLCs. This prevents us from failing backwards and then getting a reorg resulting in us losing money.
• CLOSED_CHANNEL_UPDATE_ID
  The update ID used for a ChannelMonitorUpdate that is either:

Type Aliases

• TransactionOutputs
  Transaction outputs to watch for on-chain spends.