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 (ie
called funding_transaction_generated for outbound channels).
Note that you can be a bit lazier about writing out ChannelManager than you can be with
ChannelMonitors. With ChannelMonitors you MUST write each monitor update out to disk before
returning from ManyChannelMonitor::add_update_monitor, 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
ChannelMonitors 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 (Sha256dHash, ChannelManager), which
tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
the "reorg path" (ie call block_disconnected() until you get to a common block and then call
block_connected() to step towards your best block) upon deserialization before using the
object!
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.
panics if channel_value_satoshis is >= MAX_FUNDING_SATOSHIS
!
Creates a new outbound channel to the given remote node and with the given value.
user_id will be provided back as user_channel_id in FundingGenerationReady and
FundingBroadcastSafe events to allow tracking of which events correspond with which
create_channel call. Note that user_channel_id defaults to 0 for inbound channels, so you
may wish to avoid using 0 for user_id here.
If successful, will generate a SendOpenChannel message event, so you should probably poll
PeerManager::process_events afterwards.
Raises APIError::APIMisuseError when channel_value_satoshis > 2**24 or push_msat is
greater than channel_value_satoshis * 1k or channel_value_satoshis is < 1000.
Gets the list of open channels, in random order. See ChannelDetail field documentation for
more information.
Gets the list of usable channels, in random order. Useful as an argument to
Router::get_route to ensure non-announced channels are used.
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.
May generate a SendShutdown message event on success, which should be relayed.
Force closes a channel, immediately broadcasting the latest local commitment transaction to
the chain and rejecting new HTLCs on the given channel.
Force close all channels, immediately broadcasting the latest local commitment transaction
for each to the chain and rejecting new HTLCs on each.
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.
Note that if the payment_hash already exists elsewhere (eg you're sending a duplicative
payment), we don't do anything to stop you! We always try to ensure that if the provided
next hop knows the preimage to payment_hash they can claim an additional amount as
specified in the last hop in the route! Thus, you should probably do your own
payment_preimage tracking (which you should already be doing as they represent "proof of
payment") and prevent double-sends yourself.
May generate a SendHTLCs message event on success, which should be relayed.
Raises APIError::RoutError when invalid route or forward parameter
(cltv_delta, fee, node public key) is specified.
Raises 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).
Raised APIError::MonitorUpdateFailed if a new monitor update failure prevented sending the
relevant updates.
In case of APIError::RouteError/APIError::ChannelUnavailable, the payment send has failed
and you may wish to retry via a different route immediately.
In case of APIError::MonitorUpdateFailed, the commitment update has been irrevocably
committed on our end and we're just waiting for a monitor update to send it. Do NOT retry
the payment via a different route unless you intend to pay twice!
Call this upon creation of a funding transaction for the given channel.
Note that ALL inputs in the transaction pointed to by funding_txo MUST spend SegWit outputs
or your counterparty can steal your funds!
Panics if a funding transaction has already been provided for this channel.
May panic if the funding_txo is duplicative with some other channel (note that this should
be trivially prevented by using unique funding transaction keys per-channel).
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.
Indicates that the preimage for payment_hash is unknown or the received amount is incorrect
after a PaymentReceived event, failing the HTLC back to its origin and freeing resources
along the path (including in our own channel on which we received it).
Returns false if no payment was found to fail backwards, true if the process of failing the
HTLC backwards has been started.
Provides a payment preimage in response to a PaymentReceived event, returning true and
generating message events for the net layer to claim the payment, if possible. Thus, you
should probably kick the net layer to go send messages if this returns true!
May panic if called except in response to a PaymentReceived event.
Gets the node_id held by this ChannelManager
Used to restore channels to normal operation after a
ChannelMonitorUpdateErr::TemporaryFailure was returned from a channel monitor update
operation.