Module lightning::ln::channelmanager

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 Router 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

• BlindedForward
  Information used to forward or fail this HTLC that is being forwarded within a blinded path.
• ChainParameters
  Chain-related parameters used to construct a new ChannelManager.
• ChannelCounterparty
  Channel parameters which apply to our counterparty. These are split out from ChannelDetails to better separate parameters.
• ChannelDetails
  Details of a channel, as returned by ChannelManager::list_channels and ChannelManager::list_usable_channels
• ChannelManager
  A lightning node’s channel state machine and payment management logic, which facilitates sending, forwarding, and receiving payments through lightning channels.
• ChannelManagerReadArgs
  Arguments for the creation of a ChannelManager that are not deserialized.
• CounterpartyForwardingInfo
  Information needed for constructing an invoice route hint for this channel.
• InboundHTLCDetailsNon-fuzzing
  Exposes details around pending inbound HTLCs.
• InterceptId
  An identifier used to uniquely identify an intercepted HTLC to LDK.
• OutboundHTLCDetailsNon-fuzzing
  Exposes details around pending outbound HTLCs.
• PaymentId
  A user-provided identifier in ChannelManager::send_payment used to uniquely identify a payment and ensure idempotency in LDK.
• PendingHTLCInfo
  Information about an incoming HTLC, including the PendingHTLCRouting describing where it should go next.
• PhantomRouteHints
  Route hints used in constructing invoices for [phantom node payents].
• RecipientOnionFields
  Information which is provided, encrypted, to the payment recipient when sending HTLCs.

Enums

• BlindedFailure
  Whether this blinded HTLC is being failed backwards by the introduction node or a blinded node, which determines the failure message that should be used.
• ChannelShutdownState
  Further information on the details of the channel shutdown. Upon channels being forced closed (i.e. commitment transaction confirmation detected by ChainMonitor), ChannelShutdownState will be set to ShutdownComplete or the channel will be removed shortly. Also note, that in normal operation, peers could disconnect at any of these states and require peer re-connection before making progress onto other states
• FailureCode
  This enum is used to specify which error data to send to peers when failing back an HTLC using ChannelManager::fail_htlc_backwards_with_reason.
• InboundHTLCStateDetailsNon-fuzzing
  Exposes the state of pending inbound HTLCs.
• OutboundHTLCStateDetailsNon-fuzzing
  Exposes the state of pending outbound HTLCs.
• PaymentSendFailure
  If a payment fails to send with ChannelManager::send_payment_with_route, 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.
• PendingHTLCRouting
  Information about where a received HTLC(’s onion) has indicated the HTLC should go.
• ProbeSendFailure
  Indicates that we failed to send a payment probe. Further errors may be surfaced later via Event::ProbeFailed.
• RecentPaymentDetails
  Used by ChannelManager::list_recent_payments to express the status of recent payments. These include payments that have yet to find a successful path, or have unresolved HTLCs.
• Retry
  Strategies available to retry payment path failures.
• RetryableSendFailure
  Indicates an immediate error on ChannelManager::send_payment. Further errors may be surfaced later via Event::PaymentPathFailed and Event::PaymentFailed.

Constants

• BREAKDOWN_TIMEOUT
  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).
• MIN_CLTV_EXPIRY_DELTA
  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.
• MIN_FINAL_CLTV_EXPIRY_DELTA
  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_delta field to at least this value.

Traits

• AChannelManager
  A trivial trait which describes any ChannelManager.

Functions

• provided_init_features
  Fetches the set of InitFeatures flags that are provided by or required by ChannelManager.

Type Aliases

• SimpleArcChannelManagerNon-c_bindings
  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 NodeSigner, EntropySource, and SignerProvider for its keys manager, or, respectively, Router for its router, but this type alias chooses the concrete types of KeysManager and DefaultRouter.
• SimpleRefChannelManagerNon-c_bindings
  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 issues such as overly long function definitions. Note that the ChannelManager can take any type that implements NodeSigner, EntropySource, and SignerProvider for its keys manager, or, respectively, Router for its router, but this type alias chooses the concrete types of KeysManager and DefaultRouter.