Module lightning::chain::channelmonitor [−][src]
Expand description
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
A ChannelMonitor handles chain events (blocks connected and disconnected) and generates on-chain transactions to ensure no loss of funds occurs.
An update generated by the underlying Channel itself which contains some new information the ChannelMonitor should be made aware of.
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.
General Err type for ChannelMonitor actions. Generally, this implies that the data provided is inconsistent with the ChannelMonitor being called. eg for ChannelMonitor::update_monitor this means you tried to update a monitor for a different channel or the ChannelMonitorUpdate was corrupted. Contains a developer-readable error message.
Enums
An error enum representing a failure to persist a channel monitor update.
An event to be processed by the ChannelManager.
Constants
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.
If:
(1) a channel has been force closed and
(2) we receive a preimage from a forward link that allows us to spend an HTLC output on
this channel’s (the backward link’s) broadcasted commitment transaction
then we allow the ChannelManager to send a ChannelMonitorUpdate with this update ID,
with the update providing said payment preimage. No other update types are allowed after
force-close.
Traits
Persist defines behavior for persisting channel monitors: this could mean
writing once to disk, and/or uploading to one or more backup services.
Type Definitions
Transaction outputs to watch for on-chain spends.