Struct breez_sdk_liquid::lightning::ln::channelmanager::ChannelDetails

pub struct ChannelDetails {

    pub channel_id: ChannelId,
    pub counterparty: ChannelCounterparty,
    pub funding_txo: Option<OutPoint>,
    pub channel_type: Option<Features<ChannelTypeContext>>,
    pub short_channel_id: Option<u64>,
    pub outbound_scid_alias: Option<u64>,
    pub inbound_scid_alias: Option<u64>,
    pub channel_value_satoshis: u64,
    pub unspendable_punishment_reserve: Option<u64>,
    pub user_channel_id: u128,
    pub feerate_sat_per_1000_weight: Option<u32>,
    pub balance_msat: u64,
    pub outbound_capacity_msat: u64,
    pub next_outbound_htlc_limit_msat: u64,
    pub next_outbound_htlc_minimum_msat: u64,
    pub inbound_capacity_msat: u64,
    pub confirmations_required: Option<u32>,
    pub confirmations: Option<u32>,
    pub force_close_spend_delay: Option<u16>,
    pub is_outbound: bool,
    pub is_channel_ready: bool,
    pub channel_shutdown_state: Option<ChannelShutdownState>,
    pub is_usable: bool,
    pub is_public: bool,
    pub inbound_htlc_minimum_msat: Option<u64>,
    pub inbound_htlc_maximum_msat: Option<u64>,
    pub config: Option<ChannelConfig>,
}

Details of a channel, as returned by ChannelManager::list_channels and ChannelManager::list_usable_channels

Fields

channel_id: ChannelId

The channel’s ID (prior to funding transaction generation, this is a random 32 bytes, thereafter this is the txid of the funding transaction xor the funding transaction output). Note that this means this value is not persistent - it can change once during the lifetime of the channel.

counterparty: ChannelCounterparty

Parameters which apply to our counterparty. See individual fields for more information.

funding_txo: Option<OutPoint>

The Channel’s funding transaction output, if we’ve negotiated the funding transaction with our counterparty already.

Note that, if this has been set, channel_id will be equivalent to funding_txo.unwrap().to_channel_id().

channel_type: Option<Features<ChannelTypeContext>>

The features which this channel operates with. See individual features for more info.

None until negotiation completes and the channel type is finalized.

short_channel_id: Option<u64>

The position of the funding transaction in the chain. None if the funding transaction has not yet been confirmed and the channel fully opened.

Note that if inbound_scid_alias is set, it must be used for invoices and inbound payments instead of this. See get_inbound_payment_scid.

For channels with confirmations_required set to Some(0), outbound_scid_alias may be used in place of this in outbound routes. See get_outbound_payment_scid.

outbound_scid_alias: Option<u64>

An optional short_channel_id alias for this channel, randomly generated by us and usable in place of short_channel_id to reference the channel in outbound routes when the channel has not yet been confirmed (as long as confirmations_required is Some(0)).

This will be None as long as the channel is not available for routing outbound payments.

inbound_scid_alias: Option<u64>

An optional short_channel_id alias for this channel, randomly generated by our counterparty and usable in place of short_channel_id in invoice route hints. Our counterparty will recognize the alias provided here in place of the short_channel_id when they see a payment to be routed to us.

Our counterparty may choose to rotate this value at any time, though will always recognize previous values for inbound payment forwarding.

channel_value_satoshis: u64

The value, in satoshis, of this channel as appears in the funding output

unspendable_punishment_reserve: Option<u64>

The value, in satoshis, that must always be held in the channel for us. This value ensures that if we broadcast a revoked state, our counterparty can punish us by claiming at least this value on chain.

This value is not included in outbound_capacity_msat as it can never be spent.

This value will be None for outbound channels until the counterparty accepts the channel.

user_channel_id: u128

The user_channel_id value passed in to ChannelManager::create_channel for outbound channels, or to ChannelManager::accept_inbound_channel for inbound channels if UserConfig::manually_accept_inbound_channels config flag is set to true. Otherwise user_channel_id will be randomized for an inbound channel. This may be zero for objects serialized with LDK versions prior to 0.0.113.

feerate_sat_per_1000_weight: Option<u32>

The currently negotiated fee rate denominated in satoshi per 1000 weight units, which is applied to commitment and HTLC transactions.

This value will be None for objects serialized with LDK versions prior to 0.0.115.

balance_msat: u64

Our total balance. This is the amount we would get if we close the channel. This value is not exact. Due to various in-flight changes and feerate changes, exactly this amount is not likely to be recoverable on close.

This does not include any pending HTLCs which are not yet fully resolved (and, thus, whose balance is not available for inclusion in new outbound HTLCs). This further does not include any pending outgoing HTLCs which are awaiting some other resolution to be sent. This does not consider any on-chain fees.

See also ChannelDetails::outbound_capacity_msat

outbound_capacity_msat: u64

The available outbound capacity for sending HTLCs to the remote peer. This does not include any pending HTLCs which are not yet fully resolved (and, thus, whose balance is not available for inclusion in new outbound HTLCs). This further does not include any pending outgoing HTLCs which are awaiting some other resolution to be sent.

See also ChannelDetails::balance_msat

This value is not exact. Due to various in-flight changes, feerate changes, and our conflict-avoidance policy, exactly this amount is not likely to be spendable. However, we should be able to spend nearly this amount.

next_outbound_htlc_limit_msat: u64

The available outbound capacity for sending a single HTLC to the remote peer. This is similar to ChannelDetails::outbound_capacity_msat but it may be further restricted by the current state and per-HTLC limit(s). This is intended for use when routing, allowing us to use a limit as close as possible to the HTLC limit we can currently send.

See also ChannelDetails::next_outbound_htlc_minimum_msat, ChannelDetails::balance_msat, and ChannelDetails::outbound_capacity_msat.

next_outbound_htlc_minimum_msat: u64

The minimum value for sending a single HTLC to the remote peer. This is the equivalent of ChannelDetails::next_outbound_htlc_limit_msat but represents a lower-bound, rather than an upper-bound. This is intended for use when routing, allowing us to ensure we pick a route which is valid.

inbound_capacity_msat: u64

The available inbound capacity for the remote peer to send HTLCs to us. This does not include any pending HTLCs which are not yet fully resolved (and, thus, whose balance is not available for inclusion in new inbound HTLCs). Note that there are some corner cases not fully handled here, so the actual available inbound capacity may be slightly higher than this.

This value is not exact. Due to various in-flight changes, feerate changes, and our counterparty’s conflict-avoidance policy, exactly this amount is not likely to be spendable. However, our counterparty should be able to spend nearly this amount.

confirmations_required: Option<u32>

The number of required confirmations on the funding transaction before the funding will be considered “locked”. This number is selected by the channel fundee (i.e. us if is_outbound is not set), and can be selected for inbound channels with ChannelHandshakeConfig::minimum_depth or limited for outbound channels with ChannelHandshakeLimits::max_minimum_depth.

This value will be None for outbound channels until the counterparty accepts the channel.

confirmations: Option<u32>

The current number of confirmations on the funding transaction.

This value will be None for objects serialized with LDK versions prior to 0.0.113.

force_close_spend_delay: Option<u16>

The number of blocks (after our commitment transaction confirms) that we will need to wait until we can claim our funds after we force-close the channel. During this time our counterparty is allowed to punish us if we broadcasted a stale state. If our counterparty force-closes the channel and broadcasts a commitment transaction we do not have to wait any time to claim our non-HTLC-encumbered funds.

This value will be None for outbound channels until the counterparty accepts the channel.

is_outbound: bool

True if the channel was initiated (and thus funded) by us.

is_channel_ready: bool

True if the channel is confirmed, channel_ready messages have been exchanged, and the channel is not currently being shut down. channel_ready message exchange implies the required confirmation count has been reached (and we were connected to the peer at some point after the funding transaction received enough confirmations). The required confirmation count is provided in confirmations_required.

channel_shutdown_state: Option<ChannelShutdownState>

The stage of the channel’s shutdown. None for ChannelDetails serialized on LDK versions prior to 0.0.116.

is_usable: bool

True if the channel is (a) confirmed and channel_ready messages have been exchanged, (b) the peer is connected, and (c) the channel is not currently negotiating a shutdown.

This is a strict superset of is_channel_ready.

is_public: bool

True if this channel is (or will be) publicly-announced.

inbound_htlc_minimum_msat: Option<u64>

The smallest value HTLC (in msat) we will accept, for this channel. This field is only None for ChannelDetails objects serialized prior to LDK 0.0.107

inbound_htlc_maximum_msat: Option<u64>

The largest value HTLC (in msat) we currently will accept, for this channel.

config: Option<ChannelConfig>

Set of configurable parameters that affect channel operation.

This field is only None for ChannelDetails objects serialized prior to LDK 0.0.109.

Implementations

impl ChannelDetails

pub fn get_inbound_payment_scid(&self) -> Option<u64>

Gets the current SCID which should be used to identify this channel for inbound payments. This should be used for providing invoice hints or in any other context where our counterparty will forward a payment to us.

This is either the ChannelDetails::inbound_scid_alias, if set, or the ChannelDetails::short_channel_id. See those for more information.

pub fn get_outbound_payment_scid(&self) -> Option<u64>

Gets the current SCID which should be used to identify this channel for outbound payments. This should be used in Routes to describe the first hop or in other contexts where we’re sending or forwarding a payment outbound over this channel.

This is either the ChannelDetails::short_channel_id, if set, or the ChannelDetails::outbound_scid_alias. See those for more information.

Trait Implementations

impl Clone for ChannelDetails

fn clone(&self) -> ChannelDetails

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ChannelDetails

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl PartialEq for ChannelDetails

fn eq(&self, other: &ChannelDetails) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Readable for ChannelDetails

fn read<R>(reader: &mut R) -> Result<ChannelDetails, DecodeError>

where R: Read,

Reads a Self in from the given Read.

impl Writeable for ChannelDetails

fn write<W>(&self, writer: &mut W) -> Result<(), Error>

where W: Writer,

Writes self out to the given Writer.

fn encode(&self) -> Vec<u8>

Writes self out to a Vec<u8>.

fn serialized_length(&self) -> usize

Gets the length of this object after it has been serialized. This can be overridden to optimize cases where we prepend an object with its length.

impl StructuralPartialEq for ChannelDetails