Module channelmanager
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 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§
- Chain
Parameters - Chain-related parameters used to construct a new
ChannelManager. - Channel
Counterparty - Channel parameters which apply to our counterparty. These are split out from
ChannelDetailsto better separate parameters. - Channel
Details - Details of a channel, as returned by
ChannelManager::list_channelsandChannelManager::list_usable_channels - Channel
Manager - 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.
- Channel
Manager Read Args - Arguments for the creation of a ChannelManager that are not deserialized.
- Counterparty
Forwarding Info - Information needed for constructing an invoice route hint for this channel.
- Intercept
Id - An identifier used to uniquely identify an intercepted HTLC to LDK.
- Payment
Id - A user-provided identifier in
ChannelManager::send_paymentused to uniquely identify a payment and ensure idempotency in LDK. - Phantom
Route Hints - Route hints used in constructing invoices for [phantom node payents].
- Recipient
Onion Fields - Information which is provided, encrypted, to the payment recipient when sending HTLCs.
Enums§
- Channel
Shutdown State - 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 toShutdownCompleteor 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 - Failure
Code - 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. - Payment
Send Failure - 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. - Probe
Send Failure - Indicates that we failed to send a payment probe. Further errors may be surfaced later via
Event::ProbeFailed. - Recent
Payment Details - Used by
ChannelManager::list_recent_paymentsto 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.
- Retryable
Send Failure - Indicates an immediate error on
ChannelManager::send_payment. Further errors may be surfaced later viaEvent::PaymentPathFailedandEvent::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_deltafield to at least this value.
Traits§
- AChannel
Manager - A trivial trait which describes any
ChannelManager.
Functions§
- provided_
init_ features - Fetches the set of
InitFeaturesflags that are provided by or required byChannelManager.
Type Aliases§
- Simple
ArcChannel Manager SimpleArcChannelManageris useful when you need aChannelManagerwith a static lifetime, e.g. when you’re usinglightning-net-tokio(sincetokio::spawnrequires parameters with static lifetimes). Other times you can afford a reference, which is more efficient, in which caseSimpleRefChannelManageris the more appropriate type. Defining these type aliases prevents issues such as overly long function definitions. Note that theChannelManagercan take any type that implementsNodeSigner,EntropySource, andSignerProviderfor its keys manager, or, respectively,Routerfor its router, but this type alias chooses the concrete types ofKeysManagerandDefaultRouter.- Simple
RefChannel Manager SimpleRefChannelManageris a type alias for a ChannelManager reference, and is the reference counterpart to theSimpleArcChannelManagertype 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 (sincetokio::spawnrequires 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 implementsNodeSigner,EntropySource, andSignerProviderfor its keys manager, or, respectively,Routerfor its router, but this type alias chooses the concrete types ofKeysManagerandDefaultRouter.