Class ChannelManager


  • public class ChannelManager
    extends Object
    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. Implements [`ChannelMessageHandler`], handling the multi-channel parts and passing things through to individual Channels. Implements [`Writeable`] to write out all channel state to disk. Implies [`peer_disconnected`] for all peers during write/read (though does not modify this instance, only the instance being serialized). This will result in any channels which have not yet exchanged [`funding_created`] (i.e., called [`funding_transaction_generated`] for outbound channels) being closed. Note that you can be a bit lazier about writing out `ChannelManager` than you can be with [`ChannelMonitor`]. With [`ChannelMonitor`] you MUST write each monitor update out to disk before returning from [`chain::Watch::watch_channel`]/[`update_channel`], with ChannelManagers, writing updates happens out-of-band (and will prevent any other `ChannelManager` operations from occurring during the serialization process). If the deserialized version is out-of-date compared to the [`ChannelMonitor`] passed by reference to [`read`], those channels will be force-closed based on the `ChannelMonitor` state and no funds will be lost (mod on-chain transaction fees). Note that the deserializer is only implemented for `(`[`BlockHash`]`, `[`ChannelManager`]`)`, which tells you the last block hash which was connected. You should get the best block tip before using the manager. See [`chain::Listen`] and [`chain::Confirm`] for more details. Note that `ChannelManager` is responsible for tracking liveness of its channels and generating [`ChannelUpdate`] messages informing peers that the channel is temporarily disabled. To avoid spam due to quick disconnection/reconnection, updates are not sent until the channel has been offline for a full minute. In order to track this, you must call [`timer_tick_occurred`] roughly once per minute, though it doesn't have to be perfect. To avoid trivial DoS issues, `ChannelManager` limits the number of inbound connections and inbound channels without confirmed funding transactions. This may result in nodes which we do not have a channel with being unable to connect to us or open new channels with us if we have many peers with unfunded channels. Because it is an indication of trust, inbound channels which we've accepted as 0conf are exempted from the count of unfunded channels. Similarly, outbound channels and connections are never limited. Please ensure you limit the count of such channels yourself. Rather than using a plain `ChannelManager`, it is preferable to use either a [`SimpleArcChannelManager`] a [`SimpleRefChannelManager`], for conciseness. See their documentation for more details, but essentially you should default to using a [`SimpleRefChannelManager`], and use a [`SimpleArcChannelManager`] when you require a `ChannelManager` with a static lifetime, such as when you're using lightning-net-tokio. [`peer_disconnected`]: msgs::ChannelMessageHandler::peer_disconnected [`funding_created`]: msgs::FundingCreated [`funding_transaction_generated`]: Self::funding_transaction_generated [`BlockHash`]: bitcoin::hash_types::BlockHash [`update_channel`]: chain::Watch::update_channel [`ChannelUpdate`]: msgs::ChannelUpdate [`timer_tick_occurred`]: Self::timer_tick_occurred [`read`]: ReadableArgs::read
    • Method Detail

      • of

        public static ChannelManager of​(FeeEstimator fee_est,
                                        Watch chain_monitor,
                                        BroadcasterInterface tx_broadcaster,
                                        Router router,
                                        Logger logger,
                                        EntropySource entropy_source,
                                        NodeSigner node_signer,
                                        SignerProvider signer_provider,
                                        UserConfig config,
                                        ChainParameters params)
        Constructs a new `ChannelManager` to hold several channels and route between them. This is the main \"logic hub\" for all channel-related actions, and implements [`ChannelMessageHandler`]. Non-proportional fees are fixed according to our risk using the provided fee estimator. Users need to notify the new `ChannelManager` when a new block is connected or disconnected using its [`block_connected`] and [`block_disconnected`] methods, starting from after [`params.best_block.block_hash`]. See [`chain::Listen`] and [`chain::Confirm`] for more details. [`block_connected`]: chain::Listen::block_connected [`block_disconnected`]: chain::Listen::block_disconnected [`params.best_block.block_hash`]: chain::BestBlock::block_hash
      • get_current_default_configuration

        public UserConfig get_current_default_configuration()
        Gets the current configuration applied to all new channels.
      • create_channel

        public Result__u832APIErrorZ create_channel​(byte[] their_network_key,
                                                    long channel_value_satoshis,
                                                    long push_msat,
                                                    UInt128 user_channel_id,
                                                    @Nullable
                                                    UserConfig override_config)
        Creates a new outbound channel to the given remote node and with the given value. `user_channel_id` will be provided back as in [`Event::FundingGenerationReady::user_channel_id`] to allow tracking of which events correspond with which `create_channel` call. Note that the `user_channel_id` defaults to a randomized value for inbound channels. `user_channel_id` has no meaning inside of LDK, it is simply copied to events and otherwise ignored. Raises [`APIError::APIMisuseError`] when `channel_value_satoshis` > 2**24 or `push_msat` is greater than `channel_value_satoshis * 1k` or `channel_value_satoshis < 1000`. Note that we do not check if you are currently connected to the given peer. If no connection is available, the outbound `open_channel` message may fail to send, resulting in the channel eventually being silently forgotten (dropped on reload). Returns the new Channel's temporary `channel_id`. This ID will appear as [`Event::FundingGenerationReady::temporary_channel_id`] and in [`ChannelDetails::channel_id`] until after [`ChannelManager::funding_transaction_generated`] is called, swapping the Channel's ID for one derived from the funding transaction's TXID. If the counterparty rejects the channel immediately, this temporary ID will appear in [`Event::ChannelClosed::channel_id`]. [`Event::FundingGenerationReady::user_channel_id`]: events::Event::FundingGenerationReady::user_channel_id [`Event::FundingGenerationReady::temporary_channel_id`]: events::Event::FundingGenerationReady::temporary_channel_id [`Event::ChannelClosed::channel_id`]: events::Event::ChannelClosed::channel_id Note that override_config (or a relevant inner pointer) may be NULL or all-0s to represent None
      • list_channels

        public ChannelDetails[] list_channels()
        Gets the list of open channels, in random order. See [`ChannelDetails`] field documentation for more information.
      • list_usable_channels

        public ChannelDetails[] list_usable_channels()
        Gets the list of usable channels, in random order. Useful as an argument to [`Router::find_route`] to ensure non-announced channels are used. These are guaranteed to have their [`ChannelDetails::is_usable`] value set to true, see the documentation for [`ChannelDetails::is_usable`] for more info on exactly what the criteria are.
      • list_channels_with_counterparty

        public ChannelDetails[] list_channels_with_counterparty​(byte[] counterparty_node_id)
        Gets the list of channels we have with a given counterparty, in random order.
      • list_recent_payments

        public RecentPaymentDetails[] list_recent_payments()
        Returns in an undefined order recent payments that -- if not fulfilled -- have yet to find a successful path, or have unresolved HTLCs. This can be useful for payments that may have been prepared, but ultimately not sent, as a result of a crash. If such a payment exists, is not listed here, and an [`Event::PaymentSent`] has not been received, you may consider resending the payment. [`Event::PaymentSent`]: events::Event::PaymentSent
      • close_channel

        public Result_NoneAPIErrorZ close_channel​(byte[] channel_id,
                                                  byte[] counterparty_node_id)
        Begins the process of closing a channel. After this call (plus some timeout), no new HTLCs will be accepted on the given channel, and after additional timeout/the closing of all pending HTLCs, the channel will be closed on chain. If we are the channel initiator, we will pay between our [`Background`] and [`ChannelConfig::force_close_avoidance_max_fee_satoshis`] plus our [`Normal`] fee estimate. If our counterparty is the channel initiator, we will require a channel closing transaction feerate of at least our [`Background`] feerate or the feerate which would appear on a force-closure transaction, whichever is lower. We will allow our counterparty to pay as much fee as they'd like, however. May generate a [`SendShutdown`] message event on success, which should be relayed. [`ChannelConfig::force_close_avoidance_max_fee_satoshis`]: crate::util::config::ChannelConfig::force_close_avoidance_max_fee_satoshis [`Background`]: crate::chain::chaininterface::ConfirmationTarget::Background [`Normal`]: crate::chain::chaininterface::ConfirmationTarget::Normal [`SendShutdown`]: crate::events::MessageSendEvent::SendShutdown
      • close_channel_with_target_feerate

        public Result_NoneAPIErrorZ close_channel_with_target_feerate​(byte[] channel_id,
                                                                      byte[] counterparty_node_id,
                                                                      int target_feerate_sats_per_1000_weight)
        Begins the process of closing a channel. After this call (plus some timeout), no new HTLCs will be accepted on the given channel, and after additional timeout/the closing of all pending HTLCs, the channel will be closed on chain. `target_feerate_sat_per_1000_weight` has different meanings depending on if we initiated the channel being closed or not: If we are the channel initiator, we will pay at least this feerate on the closing transaction. The upper-bound is set by [`ChannelConfig::force_close_avoidance_max_fee_satoshis`] plus our [`Normal`] fee estimate (or `target_feerate_sat_per_1000_weight`, if it is greater). If our counterparty is the channel initiator, we will refuse to accept a channel closure transaction feerate below `target_feerate_sat_per_1000_weight` (or the feerate which will appear on a force-closure transaction, whichever is lower). May generate a [`SendShutdown`] message event on success, which should be relayed. [`ChannelConfig::force_close_avoidance_max_fee_satoshis`]: crate::util::config::ChannelConfig::force_close_avoidance_max_fee_satoshis [`Background`]: crate::chain::chaininterface::ConfirmationTarget::Background [`Normal`]: crate::chain::chaininterface::ConfirmationTarget::Normal [`SendShutdown`]: crate::events::MessageSendEvent::SendShutdown
      • force_close_broadcasting_latest_txn

        public Result_NoneAPIErrorZ force_close_broadcasting_latest_txn​(byte[] channel_id,
                                                                        byte[] counterparty_node_id)
        Force closes a channel, immediately broadcasting the latest local transaction(s) and rejecting new HTLCs on the given channel. Fails if `channel_id` is unknown to the manager, or if the `counterparty_node_id` isn't the counterparty of the corresponding channel.
      • force_close_without_broadcasting_txn

        public Result_NoneAPIErrorZ force_close_without_broadcasting_txn​(byte[] channel_id,
                                                                         byte[] counterparty_node_id)
        Force closes a channel, rejecting new HTLCs on the given channel but skips broadcasting the latest local transaction(s). Fails if `channel_id` is unknown to the manager, or if the `counterparty_node_id` isn't the counterparty of the corresponding channel. You can always get the latest local transaction(s) to broadcast from [`ChannelMonitor::get_latest_holder_commitment_txn`].
      • force_close_all_channels_broadcasting_latest_txn

        public void force_close_all_channels_broadcasting_latest_txn()
        Force close all channels, immediately broadcasting the latest local commitment transaction for each to the chain and rejecting new HTLCs on each.
      • force_close_all_channels_without_broadcasting_txn

        public void force_close_all_channels_without_broadcasting_txn()
        Force close all channels rejecting new HTLCs on each but without broadcasting the latest local transaction(s).
      • send_payment_with_route

        public Result_NonePaymentSendFailureZ send_payment_with_route​(Route route,
                                                                      byte[] payment_hash,
                                                                      RecipientOnionFields recipient_onion,
                                                                      byte[] payment_id)
        Sends a payment along a given route. Value parameters are provided via the last hop in route, see documentation for [`RouteHop`] fields for more info. May generate [`UpdateHTLCs`] message(s) event on success, which should be relayed (e.g. via [`PeerManager::process_events`]). # Avoiding Duplicate Payments If a pending payment is currently in-flight with the same [`PaymentId`] provided, this method will error with an [`APIError::InvalidRoute`]. Note, however, that once a payment is no longer pending (either via [`ChannelManager::abandon_payment`], or handling of an [`Event::PaymentSent`] or [`Event::PaymentFailed`]) LDK will not stop you from sending a second payment with the same [`PaymentId`]. Thus, in order to ensure duplicate payments are not sent, you should implement your own tracking of payments, including state to indicate once a payment has completed. Because you should also ensure that [`PaymentHash`]es are not re-used, for simplicity, you should consider using the [`PaymentHash`] as the key for tracking payments. In that case, the [`PaymentId`] should be a copy of the [`PaymentHash`] bytes. Additionally, in the scenario where we begin the process of sending a payment, but crash before `send_payment` returns (or prior to [`ChannelMonitorUpdate`] persistence if you're using [`ChannelMonitorUpdateStatus::InProgress`]), the payment may be lost on restart. See [`ChannelManager::list_recent_payments`] for more information. # Possible Error States on [`PaymentSendFailure`] Each path may have a different return value, and [`PaymentSendFailure`] may return a `Vec` with each entry matching the corresponding-index entry in the route paths, see [`PaymentSendFailure`] for more info. In general, a path may raise: [`APIError::InvalidRoute`] when an invalid route or forwarding parameter (cltv_delta, fee, node public key) is specified. [`APIError::ChannelUnavailable`] if the next-hop channel is not available for updates (including due to previous monitor update failure or new permanent monitor update failure). [`APIError::MonitorUpdateInProgress`] if a new monitor update failure prevented sending the relevant updates. Note that depending on the type of the [`PaymentSendFailure`] the HTLC may have been irrevocably committed to on our end. In such a case, do NOT retry the payment with a different route unless you intend to pay twice! [`Event::PaymentSent`]: events::Event::PaymentSent [`Event::PaymentFailed`]: events::Event::PaymentFailed [`UpdateHTLCs`]: events::MessageSendEvent::UpdateHTLCs [`PeerManager::process_events`]: crate::ln::peer_handler::PeerManager::process_events [`ChannelMonitorUpdateStatus::InProgress`]: crate::chain::ChannelMonitorUpdateStatus::InProgress
      • send_payment

        public Result_NoneRetryableSendFailureZ send_payment​(byte[] payment_hash,
                                                             RecipientOnionFields recipient_onion,
                                                             byte[] payment_id,
                                                             RouteParameters route_params,
                                                             Retry retry_strategy)
        Similar to [`ChannelManager::send_payment`], but will automatically find a route based on `route_params` and retry failed payment paths based on `retry_strategy`.
      • abandon_payment

        public void abandon_payment​(byte[] payment_id)
        Signals that no further retries for the given payment should occur. Useful if you have a pending outbound payment with retries remaining, but wish to stop retrying the payment before retries are exhausted. If no [`Event::PaymentFailed`] event had been generated before, one will be generated as soon as there are no remaining pending HTLCs for this payment. Note that calling this method does *not* prevent a payment from succeeding. You must still wait until you receive either a [`Event::PaymentFailed`] or [`Event::PaymentSent`] event to determine the ultimate status of a payment. If an [`Event::PaymentFailed`] event is generated and we restart without this [`ChannelManager`] having been persisted, another [`Event::PaymentFailed`] may be generated. [`Event::PaymentFailed`]: events::Event::PaymentFailed [`Event::PaymentSent`]: events::Event::PaymentSent
      • send_spontaneous_payment

        public Result_PaymentHashPaymentSendFailureZ send_spontaneous_payment​(Route route,
                                                                              @Nullable
                                                                              byte[] payment_preimage,
                                                                              RecipientOnionFields recipient_onion,
                                                                              byte[] payment_id)
        Send a spontaneous payment, which is a payment that does not require the recipient to have generated an invoice. Optionally, you may specify the preimage. If you do choose to specify the preimage, it must be a cryptographically secure random value that no intermediate node would be able to guess -- otherwise, an intermediate node may claim the payment and it will never reach the recipient. See [`send_payment`] documentation for more details on the return value of this function and idempotency guarantees provided by the [`PaymentId`] key. Similar to regular payments, you MUST NOT reuse a `payment_preimage` value. See [`send_payment`] for more information about the risks of duplicate preimage usage. Note that `route` must have exactly one path. [`send_payment`]: Self::send_payment Note that payment_preimage (or a relevant inner pointer) may be NULL or all-0s to represent None
      • send_spontaneous_payment_with_retry

        public Result_PaymentHashRetryableSendFailureZ send_spontaneous_payment_with_retry​(@Nullable
                                                                                           byte[] payment_preimage,
                                                                                           RecipientOnionFields recipient_onion,
                                                                                           byte[] payment_id,
                                                                                           RouteParameters route_params,
                                                                                           Retry retry_strategy)
        Similar to [`ChannelManager::send_spontaneous_payment`], but will automatically find a route based on `route_params` and retry failed payment paths based on `retry_strategy`. See [`PaymentParameters::for_keysend`] for help in constructing `route_params` for spontaneous payments. [`PaymentParameters::for_keysend`]: crate::routing::router::PaymentParameters::for_keysend Note that payment_preimage (or a relevant inner pointer) may be NULL or all-0s to represent None
      • send_probe

        public Result_C2Tuple_PaymentHashPaymentIdZPaymentSendFailureZ send_probe​(Path path)
        Send a payment that is probing the given route for liquidity. We calculate the [`PaymentHash`] of probes based on a static secret and a random [`PaymentId`], which allows us to easily discern them from real payments.
      • funding_transaction_generated

        public Result_NoneAPIErrorZ funding_transaction_generated​(byte[] temporary_channel_id,
                                                                  byte[] counterparty_node_id,
                                                                  byte[] funding_transaction)
        Call this upon creation of a funding transaction for the given channel. Returns an [`APIError::APIMisuseError`] if the funding_transaction spent non-SegWit outputs or if no output was found which matches the parameters in [`Event::FundingGenerationReady`]. Returns [`APIError::APIMisuseError`] if the funding transaction is not final for propagation across the p2p network. Returns [`APIError::ChannelUnavailable`] if a funding transaction has already been provided for the channel or if the channel has been closed as indicated by [`Event::ChannelClosed`]. May panic if the output found in the funding transaction is duplicative with some other channel (note that this should be trivially prevented by using unique funding transaction keys per-channel). Do NOT broadcast the funding transaction yourself. When we have safely received our counterparty's signature the funding transaction will automatically be broadcast via the [`BroadcasterInterface`] provided when this `ChannelManager` was constructed. Note that this includes RBF or similar transaction replacement strategies - lightning does not currently support replacing a funding transaction on an existing channel. Instead, create a new channel with a conflicting funding transaction. Note to keep the miner incentives aligned in moving the blockchain forward, we recommend the wallet software generating the funding transaction to apply anti-fee sniping as implemented by Bitcoin Core wallet. See for more details. [`Event::FundingGenerationReady`]: crate::events::Event::FundingGenerationReady [`Event::ChannelClosed`]: crate::events::Event::ChannelClosed
      • update_channel_config

        public Result_NoneAPIErrorZ update_channel_config​(byte[] counterparty_node_id,
                                                          byte[][] channel_ids,
                                                          ChannelConfig config)
        Atomically updates the [`ChannelConfig`] for the given channels. Once the updates are applied, each eligible channel (advertised with a known short channel ID and a change in [`forwarding_fee_proportional_millionths`], [`forwarding_fee_base_msat`], or [`cltv_expiry_delta`]) has a [`BroadcastChannelUpdate`] event message generated containing the new [`ChannelUpdate`] message which should be broadcast to the network. Returns [`ChannelUnavailable`] when a channel is not found or an incorrect `counterparty_node_id` is provided. Returns [`APIMisuseError`] when a [`cltv_expiry_delta`] update is to be applied with a value below [`MIN_CLTV_EXPIRY_DELTA`]. If an error is returned, none of the updates should be considered applied. [`forwarding_fee_proportional_millionths`]: ChannelConfig::forwarding_fee_proportional_millionths [`forwarding_fee_base_msat`]: ChannelConfig::forwarding_fee_base_msat [`cltv_expiry_delta`]: ChannelConfig::cltv_expiry_delta [`BroadcastChannelUpdate`]: events::MessageSendEvent::BroadcastChannelUpdate [`ChannelUpdate`]: msgs::ChannelUpdate [`ChannelUnavailable`]: APIError::ChannelUnavailable [`APIMisuseError`]: APIError::APIMisuseError
      • forward_intercepted_htlc

        public Result_NoneAPIErrorZ forward_intercepted_htlc​(byte[] intercept_id,
                                                             byte[] next_hop_channel_id,
                                                             byte[] next_node_id,
                                                             long amt_to_forward_msat)
        Attempts to forward an intercepted HTLC over the provided channel id and with the provided amount to forward. Should only be called in response to an [`HTLCIntercepted`] event. Intercepted HTLCs can be useful for Lightning Service Providers (LSPs) to open a just-in-time channel to a receiving node if the node lacks sufficient inbound liquidity. To make use of intercepted HTLCs, set [`UserConfig::accept_intercept_htlcs`] and use [`ChannelManager::get_intercept_scid`] to generate short channel id(s) to put in the receiver's invoice route hints. These route hints will signal to LDK to generate an [`HTLCIntercepted`] event when it receives the forwarded HTLC, and this method or [`ChannelManager::fail_intercepted_htlc`] MUST be called in response to the event. Note that LDK does not enforce fee requirements in `amt_to_forward_msat`, and will not stop you from forwarding more than you received. Errors if the event was not handled in time, in which case the HTLC was automatically failed backwards. [`UserConfig::accept_intercept_htlcs`]: crate::util::config::UserConfig::accept_intercept_htlcs [`HTLCIntercepted`]: events::Event::HTLCIntercepted
      • fail_intercepted_htlc

        public Result_NoneAPIErrorZ fail_intercepted_htlc​(byte[] intercept_id)
        Fails the intercepted HTLC indicated by intercept_id. Should only be called in response to an [`HTLCIntercepted`] event. See [`ChannelManager::forward_intercepted_htlc`]. Errors if the event was not handled in time, in which case the HTLC was automatically failed backwards. [`HTLCIntercepted`]: events::Event::HTLCIntercepted
      • process_pending_htlc_forwards

        public void process_pending_htlc_forwards()
        Processes HTLCs which are pending waiting on random forward delay. Should only really ever be called in response to a PendingHTLCsForwardable event. Will likely generate further events.
      • timer_tick_occurred

        public void timer_tick_occurred()
        Performs actions which should happen on startup and roughly once per minute thereafter. This currently includes: Increasing or decreasing the on-chain feerate estimates for our outbound channels, Broadcasting [`ChannelUpdate`] messages if we've been disconnected from our peer for more than a minute, informing the network that they should no longer attempt to route over the channel. Expiring a channel's previous [`ChannelConfig`] if necessary to only allow forwarding HTLCs with the current [`ChannelConfig`]. Removing peers which have disconnected but and no longer have any channels. Note that this may cause reentrancy through [`chain::Watch::update_channel`] calls or feerate estimate fetches. [`ChannelUpdate`]: msgs::ChannelUpdate [`ChannelConfig`]: crate::util::config::ChannelConfig
      • fail_htlc_backwards

        public void fail_htlc_backwards​(byte[] payment_hash)
        Indicates that the preimage for payment_hash is unknown or the received amount is incorrect after a PaymentClaimable event, failing the HTLC back to its origin and freeing resources along the path (including in our own channel on which we received it). Note that in some cases around unclean shutdown, it is possible the payment may have already been claimed by you via [`ChannelManager::claim_funds`] prior to you seeing (a second copy of) the [`events::Event::PaymentClaimable`] event. Alternatively, the payment may have already been failed automatically by LDK if it was nearing its expiration time. While LDK will never claim a payment automatically on your behalf (i.e. without you calling [`ChannelManager::claim_funds`]), you should still monitor for [`events::Event::PaymentClaimed`] events even for payments you intend to fail, especially on startup during which time claims that were in-progress at shutdown may be replayed.
      • fail_htlc_backwards_with_reason

        public void fail_htlc_backwards_with_reason​(byte[] payment_hash,
                                                    FailureCode failure_code)
        This is a variant of [`ChannelManager::fail_htlc_backwards`] that allows you to specify the reason for the failure. See [`FailureCode`] for valid failure codes.
      • claim_funds

        public void claim_funds​(byte[] payment_preimage)
        Provides a payment preimage in response to [`Event::PaymentClaimable`], generating any [`MessageSendEvent`]s needed to claim the payment. This method is guaranteed to ensure the payment has been claimed but only if the current height is strictly below [`Event::PaymentClaimable::claim_deadline`]. To avoid race conditions, you should wait for an [`Event::PaymentClaimed`] before considering the payment successful. It will generally be available in the next [`process_pending_events`] call. Note that if you did not set an `amount_msat` when calling [`create_inbound_payment`] or [`create_inbound_payment_for_hash`] you must check that the amount in the `PaymentClaimable` event matches your expectation. If you fail to do so and call this method, you may provide the sender \"proof-of-payment\" when they did not fulfill the full expected payment. [`Event::PaymentClaimable`]: crate::events::Event::PaymentClaimable [`Event::PaymentClaimable::claim_deadline`]: crate::events::Event::PaymentClaimable::claim_deadline [`Event::PaymentClaimed`]: crate::events::Event::PaymentClaimed [`process_pending_events`]: EventsProvider::process_pending_events [`create_inbound_payment`]: Self::create_inbound_payment [`create_inbound_payment_for_hash`]: Self::create_inbound_payment_for_hash
      • get_our_node_id

        public byte[] get_our_node_id()
        Gets the node_id held by this ChannelManager
      • accept_inbound_channel

        public Result_NoneAPIErrorZ accept_inbound_channel​(byte[] temporary_channel_id,
                                                           byte[] counterparty_node_id,
                                                           UInt128 user_channel_id)
        Accepts a request to open a channel after a [`Event::OpenChannelRequest`]. The `temporary_channel_id` parameter indicates which inbound channel should be accepted, and the `counterparty_node_id` parameter is the id of the peer which has requested to open the channel. The `user_channel_id` parameter will be provided back in [`Event::ChannelClosed::user_channel_id`] to allow tracking of which events correspond with which `accept_inbound_channel`/`accept_inbound_channel_from_trusted_peer_0conf` call. Note that this method will return an error and reject the channel, if it requires support for zero confirmations. Instead, `accept_inbound_channel_from_trusted_peer_0conf` must be used to accept such channels. [`Event::OpenChannelRequest`]: events::Event::OpenChannelRequest [`Event::ChannelClosed::user_channel_id`]: events::Event::ChannelClosed::user_channel_id
      • accept_inbound_channel_from_trusted_peer_0conf

        public Result_NoneAPIErrorZ accept_inbound_channel_from_trusted_peer_0conf​(byte[] temporary_channel_id,
                                                                                   byte[] counterparty_node_id,
                                                                                   UInt128 user_channel_id)
        Accepts a request to open a channel after a [`events::Event::OpenChannelRequest`], treating it as confirmed immediately. The `user_channel_id` parameter will be provided back in [`Event::ChannelClosed::user_channel_id`] to allow tracking of which events correspond with which `accept_inbound_channel`/`accept_inbound_channel_from_trusted_peer_0conf` call. Unlike [`ChannelManager::accept_inbound_channel`], this method accepts the incoming channel and (if the counterparty agrees), enables forwarding of payments immediately. This fully trusts that the counterparty has honestly and correctly constructed the funding transaction and blindly assumes that it will eventually confirm. If it does not confirm before we decide to close the channel, or if the funding transaction does not pay to the correct script the correct amount, *you will lose funds*. [`Event::OpenChannelRequest`]: events::Event::OpenChannelRequest [`Event::ChannelClosed::user_channel_id`]: events::Event::ChannelClosed::user_channel_id
      • create_inbound_payment

        public Result_C2Tuple_PaymentHashPaymentSecretZNoneZ create_inbound_payment​(Option_u64Z min_value_msat,
                                                                                    int invoice_expiry_delta_secs,
                                                                                    Option_u16Z min_final_cltv_expiry_delta)
        Gets a payment secret and payment hash for use in an invoice given to a third party wishing to pay us. This differs from [`create_inbound_payment_for_hash`] only in that it generates the [`PaymentHash`] and [`PaymentPreimage`] for you. The [`PaymentPreimage`] will ultimately be returned to you in the [`PaymentClaimable`], which will have the [`PaymentClaimable::purpose`] be [`PaymentPurpose::InvoicePayment`] with its [`PaymentPurpose::InvoicePayment::payment_preimage`] field filled in. That should then be passed directly to [`claim_funds`]. See [`create_inbound_payment_for_hash`] for detailed documentation on behavior and requirements. Note that a malicious eavesdropper can intuit whether an inbound payment was created by `create_inbound_payment` or `create_inbound_payment_for_hash` based on runtime. # Note If you register an inbound payment with this method, then serialize the `ChannelManager`, then deserialize it with a node running 0.0.103 and earlier, the payment will fail to be received. Errors if `min_value_msat` is greater than total bitcoin supply. If `min_final_cltv_expiry_delta` is set to some value, then the payment will not be receivable on versions of LDK prior to 0.0.114. [`claim_funds`]: Self::claim_funds [`PaymentClaimable`]: events::Event::PaymentClaimable [`PaymentClaimable::purpose`]: events::Event::PaymentClaimable::purpose [`PaymentPurpose::InvoicePayment`]: events::PaymentPurpose::InvoicePayment [`PaymentPurpose::InvoicePayment::payment_preimage`]: events::PaymentPurpose::InvoicePayment::payment_preimage [`create_inbound_payment_for_hash`]: Self::create_inbound_payment_for_hash
      • create_inbound_payment_legacy

        public Result_C2Tuple_PaymentHashPaymentSecretZAPIErrorZ create_inbound_payment_legacy​(Option_u64Z min_value_msat,
                                                                                               int invoice_expiry_delta_secs)
        Legacy version of [`create_inbound_payment`]. Use this method if you wish to share serialized state with LDK node(s) running 0.0.103 and earlier. May panic if `invoice_expiry_delta_secs` is greater than one year. # Note This method is deprecated and will be removed soon. [`create_inbound_payment`]: Self::create_inbound_payment
      • create_inbound_payment_for_hash

        public Result_PaymentSecretNoneZ create_inbound_payment_for_hash​(byte[] payment_hash,
                                                                         Option_u64Z min_value_msat,
                                                                         int invoice_expiry_delta_secs,
                                                                         Option_u16Z min_final_cltv_expiry)
        Gets a [`PaymentSecret`] for a given [`PaymentHash`], for which the payment preimage is stored external to LDK. A [`PaymentClaimable`] event will only be generated if the [`PaymentSecret`] matches a payment secret fetched via this method or [`create_inbound_payment`], and which is at least the `min_value_msat` provided here, if one is provided. The [`PaymentHash`] (and corresponding [`PaymentPreimage`]) should be globally unique, though note that LDK will not stop you from registering duplicate payment hashes for inbound payments. `min_value_msat` should be set if the invoice being generated contains a value. Any payment received for the returned [`PaymentHash`] will be required to be at least `min_value_msat` before a [`PaymentClaimable`] event will be generated, ensuring that we do not provide the sender \"proof-of-payment\" unless they have paid the required amount. `invoice_expiry_delta_secs` describes the number of seconds that the invoice is valid for in excess of the current time. This should roughly match the expiry time set in the invoice. After this many seconds, we will remove the inbound payment, resulting in any attempts to pay the invoice failing. The BOLT spec suggests 3,600 secs as a default validity time for invoices when no timeout is set. Note that we use block header time to time-out pending inbound payments (with some margin to compensate for the inaccuracy of block header timestamps). Thus, in practice we will accept a payment and generate a [`PaymentClaimable`] event for some time after the expiry. If you need exact expiry semantics, you should enforce them upon receipt of [`PaymentClaimable`]. Note that invoices generated for inbound payments should have their `min_final_cltv_expiry_delta` set to at least [`MIN_FINAL_CLTV_EXPIRY_DELTA`]. Note that a malicious eavesdropper can intuit whether an inbound payment was created by `create_inbound_payment` or `create_inbound_payment_for_hash` based on runtime. # Note If you register an inbound payment with this method, then serialize the `ChannelManager`, then deserialize it with a node running 0.0.103 and earlier, the payment will fail to be received. Errors if `min_value_msat` is greater than total bitcoin supply. If `min_final_cltv_expiry_delta` is set to some value, then the payment will not be receivable on versions of LDK prior to 0.0.114. [`create_inbound_payment`]: Self::create_inbound_payment [`PaymentClaimable`]: events::Event::PaymentClaimable
      • create_inbound_payment_for_hash_legacy

        public Result_PaymentSecretAPIErrorZ create_inbound_payment_for_hash_legacy​(byte[] payment_hash,
                                                                                    Option_u64Z min_value_msat,
                                                                                    int invoice_expiry_delta_secs)
        Legacy version of [`create_inbound_payment_for_hash`]. Use this method if you wish to share serialized state with LDK node(s) running 0.0.103 and earlier. May panic if `invoice_expiry_delta_secs` is greater than one year. # Note This method is deprecated and will be removed soon. [`create_inbound_payment_for_hash`]: Self::create_inbound_payment_for_hash
      • get_payment_preimage

        public Result_PaymentPreimageAPIErrorZ get_payment_preimage​(byte[] payment_hash,
                                                                    byte[] payment_secret)
        Gets an LDK-generated payment preimage from a payment hash and payment secret that were previously returned from [`create_inbound_payment`]. [`create_inbound_payment`]: Self::create_inbound_payment
      • get_phantom_scid

        public long get_phantom_scid()
        Gets a fake short channel id for use in receiving [phantom node payments]. These fake scids are used when constructing the phantom invoice's route hints. [phantom node payments]: crate::chain::keysinterface::PhantomKeysManager
      • get_phantom_route_hints

        public PhantomRouteHints get_phantom_route_hints()
        Gets route hints for use in receiving [phantom node payments]. [phantom node payments]: crate::chain::keysinterface::PhantomKeysManager
      • get_intercept_scid

        public long get_intercept_scid()
        Gets a fake short channel id for use in receiving intercepted payments. These fake scids are used when constructing the route hints for HTLCs intended to be intercepted. See [`ChannelManager::forward_intercepted_htlc`]. Note that this method is not guaranteed to return unique values, you may need to call it a few times to get a unique scid.
      • compute_inflight_htlcs

        public InFlightHtlcs compute_inflight_htlcs()
        Gets inflight HTLC information by processing pending outbound payments that are in our channels. May be used during pathfinding to account for in-use channel liquidity.
      • as_MessageSendEventsProvider

        public MessageSendEventsProvider as_MessageSendEventsProvider()
        Constructs a new MessageSendEventsProvider which calls the relevant methods on this_arg. This copies the `inner` pointer in this_arg and thus the returned MessageSendEventsProvider must be freed before this_arg is
      • as_EventsProvider

        public EventsProvider as_EventsProvider()
        Constructs a new EventsProvider which calls the relevant methods on this_arg. This copies the `inner` pointer in this_arg and thus the returned EventsProvider must be freed before this_arg is
      • as_Listen

        public Listen as_Listen()
        Constructs a new Listen which calls the relevant methods on this_arg. This copies the `inner` pointer in this_arg and thus the returned Listen must be freed before this_arg is
      • as_Confirm

        public Confirm as_Confirm()
        Constructs a new Confirm which calls the relevant methods on this_arg. This copies the `inner` pointer in this_arg and thus the returned Confirm must be freed before this_arg is
      • get_persistable_update_future

        public Future get_persistable_update_future()
        Gets a [`Future`] that completes when this [`ChannelManager`] needs to be persisted. Note that callbacks registered on the [`Future`] MUST NOT call back into this [`ChannelManager`] and should instead register actions to be taken later.
      • current_best_block

        public BestBlock current_best_block()
        Gets the latest best block which was connected either via the [`chain::Listen`] or [`chain::Confirm`] interfaces.
      • node_features

        public NodeFeatures node_features()
        Fetches the set of [`NodeFeatures`] flags which are provided by or required by [`ChannelManager`].
      • channel_features

        public ChannelFeatures channel_features()
        Fetches the set of [`ChannelFeatures`] flags which are provided by or required by [`ChannelManager`].
      • channel_type_features

        public ChannelTypeFeatures channel_type_features()
        Fetches the set of [`ChannelTypeFeatures`] flags which are provided by or required by [`ChannelManager`].
      • init_features

        public InitFeatures init_features()
        Fetches the set of [`InitFeatures`] flags which are provided by or required by [`ChannelManager`].
      • as_ChannelMessageHandler

        public ChannelMessageHandler as_ChannelMessageHandler()
        Constructs a new ChannelMessageHandler which calls the relevant methods on this_arg. This copies the `inner` pointer in this_arg and thus the returned ChannelMessageHandler must be freed before this_arg is
      • write

        public byte[] write()
        Serialize the ChannelManager object into a byte array which can be read by ChannelManager_read