Module lightning::ln::channelmanager
source · [−]Expand description
The top-level channel management and payment tracking stuff lives here.
The ChannelManager is the main chunk of logic implementing the lightning protocol and is responsible for tracking which channels are open, HTLCs are in flight and reestablishing those upon reconnect to the relevant peer(s).
It does not manage routing logic (see routing::router::get_route for that) nor does it manage constructing on-chain transactions (it only monitors the chain to watch for any force-closes that might imply it needs to fail HTLCs/payments/channels it manages).
Structs
Chain-related parameters used to construct a new ChannelManager.
Channel parameters which apply to our counterparty. These are split out from ChannelDetails
to better separate parameters.
Details of a channel, as returned by ChannelManager::list_channels and ChannelManager::list_usable_channels
Manager which keeps track of a number of channels and sends messages to the appropriate channel, also tracking HTLC preimages and forwarding onion packets appropriately.
Arguments for the creation of a ChannelManager that are not deserialized.
Information needed for constructing an invoice route hint for this channel.
A payment identifier used to uniquely identify a payment to LDK. (C-not exported) as we just use [u8; 32] directly
Route hints used in constructing invoices for [phantom node payents].
Enums
If a payment fails to send, it can be in one of several states. This enum is returned as the Err() type describing which state the payment is in, see the description of individual enum states for more.
Constants
The amount of time in blocks we require our counterparty wait to claim their money (ie time between when we, or our watchtower, must check for them having broadcast a theft transaction).
The minimum number of blocks between an inbound HTLC’s CLTV and the corresponding outbound HTLC’s CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.
Minimum CLTV difference between the current block height and received inbound payments.
Invoices generated for payment to us must set their min_final_cltv_expiry field to at least
this value.
Type Definitions
SimpleArcChannelManager is useful when you need a ChannelManager with a static lifetime, e.g. when you’re using lightning-net-tokio (since tokio::spawn requires parameters with static lifetimes). Other times you can afford a reference, which is more efficient, in which case SimpleRefChannelManager is the more appropriate type. Defining these type aliases prevents issues such as overly long function definitions. Note that the ChannelManager can take any type that implements KeysInterface for its keys manager, but this type alias chooses the concrete type of the KeysManager.
SimpleRefChannelManager is a type alias for a ChannelManager reference, and is the reference counterpart to the SimpleArcChannelManager type alias. Use this type by default when you don’t need a ChannelManager with a static lifetime. You’ll need a static lifetime in cases such as usage of lightning-net-tokio (since tokio::spawn requires parameters with static lifetimes). But if this is not necessary, using a reference is more efficient. Defining these type aliases helps with issues such as long function definitions. Note that the ChannelManager can take any type that implements KeysInterface for its keys manager, but this type alias chooses the concrete type of the KeysManager.