Struct lightning::ln::channelmanager::ChannelManager

pub struct ChannelManager { /* fields omitted */ }

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.

Methods

impl ChannelManager

pub fn new(
    our_network_key: SecretKey,
    fee_proportional_millionths: u32,
    announce_channels_publicly: bool,
    network: Network,
    feeest: Arc<FeeEstimator>,
    monitor: Arc<ManyChannelMonitor>,
    chain_monitor: Arc<ChainWatchInterface>,
    tx_broadcaster: Arc<BroadcasterInterface>
) -> Result<Arc<ChannelManager>, Error>

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. fee_proportional_millionths is an optional fee to charge any payments routed through us. Non-proportional fees are fixed according to our risk using the provided fee estimator. panics if channel_value_satoshis is >= (1 << 24)!

pub fn create_channel(
    &self,
    their_network_key: PublicKey,
    channel_value_satoshis: u64,
    user_id: u64
) -> Result<OpenChannel, HandleError>

Important traits for Vec<u8>

impl Write for Vec<u8>

pub fn list_channels(&self) -> Vec<ChannelDetails>

Gets the list of open channels, in random order. See ChannelDetail field documentation for more information.

pub fn close_channel(
    &self,
    channel_id: &Uint256
) -> Result<Shutdown, HandleError>

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.

pub fn send_payment(
    &self,
    route: Route,
    payment_hash: [u8; 32]
) -> Result<(), HandleError>

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. See-also docs on Channel::send_htlc_and_commit. May generate a SendHTLCs event on success, which should be relayed.

pub fn funding_transaction_generated(
    &self,
    temporary_channel_id: &Uint256,
    funding_txo: (Sha256dHash, u16)
)

Call this upon creation of a funding transaction for the given channel. Panics if a funding transaction has already been provided for this channel.

pub fn process_pending_htlc_forward(&self)

pub fn fail_htlc_backwards(&self, payment_hash: &[u8; 32]) -> bool

Indicates that the preimage for payment_hash is unknown after a PaymentReceived event.

pub fn claim_funds(&self, payment_preimage: [u8; 32]) -> bool

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.

pub fn claim_funds_internal(
    &self,
    payment_preimage: [u8; 32],
    from_user: bool
) -> bool

pub fn get_our_node_id(&self) -> PublicKey

Gets the node_id held by this ChannelManager

pub fn test_restore_channel_monitor(&self)

Used to restore channels to normal operation after a ChannelMonitorUpdateErr::TemporaryFailure was returned from a channel monitor update operation.

Trait Implementations

impl EventsProvider for ChannelManager

Important traits for Vec<u8>

impl Write for Vec<u8>

fn get_and_clear_pending_events(&self) -> Vec<Event>

impl ChainListener for ChannelManager

fn block_connected(
    &self,
    header: &BlockHeader,
    height: u32,
    txn_matched: &[&Transaction],
    indexes_of_txn_matched: &[u32]
)

Notifies a listener that a block was connected. Note that if a new script/transaction is watched during a block_connected call, the block must be re-scanned with the new script/transaction and block_connected should be called again with the same header and (at least) the new transactions. This also means those counting confirmations using block_connected callbacks should watch for duplicate headers and not count them towards confirmations!

fn block_disconnected(&self, header: &BlockHeader)

Notifies a listener that a block was disconnected. Unlike block_connected, this must never be called twice for the same disconnect event.

impl ChannelMessageHandler for ChannelManager

fn handle_open_channel(
    &self,
    their_node_id: &PublicKey,
    msg: &OpenChannel
) -> Result<AcceptChannel, HandleError>

fn handle_accept_channel(
    &self,
    their_node_id: &PublicKey,
    msg: &AcceptChannel
) -> Result<(), HandleError>

fn handle_funding_created(
    &self,
    their_node_id: &PublicKey,
    msg: &FundingCreated
) -> Result<FundingSigned, HandleError>

fn handle_funding_signed(
    &self,
    their_node_id: &PublicKey,
    msg: &FundingSigned
) -> Result<(), HandleError>

fn handle_funding_locked(
    &self,
    their_node_id: &PublicKey,
    msg: &FundingLocked
) -> Result<Option<AnnouncementSignatures>, HandleError>

fn handle_shutdown(
    &self,
    their_node_id: &PublicKey,
    msg: &Shutdown
) -> Result<(Option<Shutdown>, Option<ClosingSigned>), HandleError>

fn handle_closing_signed(
    &self,
    their_node_id: &PublicKey,
    msg: &ClosingSigned
) -> Result<Option<ClosingSigned>, HandleError>

fn handle_update_add_htlc(
    &self,
    their_node_id: &PublicKey,
    msg: &UpdateAddHTLC
) -> Result<(), HandleError>

fn handle_update_fulfill_htlc(
    &self,
    their_node_id: &PublicKey,
    msg: &UpdateFulfillHTLC
) -> Result<(), HandleError>

fn handle_update_fail_htlc(
    &self,
    their_node_id: &PublicKey,
    msg: &UpdateFailHTLC
) -> Result<Option<HTLCFailChannelUpdate>, HandleError>

fn handle_update_fail_malformed_htlc(
    &self,
    their_node_id: &PublicKey,
    msg: &UpdateFailMalformedHTLC
) -> Result<(), HandleError>

fn handle_commitment_signed(
    &self,
    their_node_id: &PublicKey,
    msg: &CommitmentSigned
) -> Result<(RevokeAndACK, Option<CommitmentSigned>), HandleError>

fn handle_revoke_and_ack(
    &self,
    their_node_id: &PublicKey,
    msg: &RevokeAndACK
) -> Result<Option<CommitmentUpdate>, HandleError>

fn handle_update_fee(
    &self,
    their_node_id: &PublicKey,
    msg: &UpdateFee
) -> Result<(), HandleError>

fn handle_announcement_signatures(
    &self,
    their_node_id: &PublicKey,
    msg: &AnnouncementSignatures
) -> Result<(), HandleError>

fn peer_disconnected(
    &self,
    their_node_id: &PublicKey,
    no_connection_possible: bool
)

Indicates a connection to the peer failed/an existing connection was lost. If no connection is believed to be possible in the future (eg they're sending us messages we don't understand or indicate they require unknown feature bits), no_connection_possible is set and any outstanding channels should be failed.