Skip to content

Update ChannelDetails docs for splicing #721

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 2, 2025
Merged

Update ChannelDetails docs for splicing #721

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 22 additions & 3 deletions src/types.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -228,12 +228,15 @@ impl fmt::Display for UserChannelId {

/// Details of a channel as returned by [`Node::list_channels`].
///
/// When a channel is spliced, most fields continue to refer to the original pre-splice channel
/// state until the splice transaction reaches sufficient confirmations to be locked (and we
/// exchange `splice_locked` messages with our peer). See individual fields for details.
///
/// [`Node::list_channels`]: crate::Node::list_channels
#[derive(Debug, Clone)]
pub struct ChannelDetails {
Copy link

@valentinewallace valentinewallace Dec 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my understanding of LDK Node, why do we duplicate this struct here vs using the rust-lightning type?

Copy link
Collaborator Author

@tnull tnull Dec 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is mostly bindings, as we don't have a good way to expose all fields on the LDK variant (e.g., InitFeatures, but we also have our own version of config: ChannelConfig as the LDK enum MaxDustHTLCExposure has tuple enum variants which our bindings generator uniffi doesn't support). It's also due to the docs on ChannelDetails referring to LDK APIs that aren't exposed in LDK Node. And, lastly, in LDK Node we also made the decision to not expose LDK's forked OutPoint variant but rather consistently only ever expose bitcoin::OutPoint.

Copy link

@valentinewallace valentinewallace Dec 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, got it. Thanks for that explanation!

/// The channel ID (prior to funding transaction generation, this is a random 32-byte
/// identifier, afterwards this is the transaction ID of the funding transaction XOR the
/// funding transaction output).
/// The channel's ID (prior to initial channel setup this is a random 32 bytes, thereafter it
/// is derived from channel funding or key material).
///
/// Note that this means this value is *not* persistent - it can change once during the
/// lifetime of the channel.
Expand All @@ -242,6 +245,10 @@ pub struct ChannelDetails {
pub counterparty_node_id: PublicKey,
/// The channel's funding transaction output, if we've negotiated the funding transaction with
/// our counterparty already.
///
/// When a channel is spliced, this continues to refer to the original pre-splice channel
/// state until the splice transaction reaches sufficient confirmations to be locked (and we
/// exchange `splice_locked` messages with our peer).
pub funding_txo: Option<OutPoint>,
/// The position of the funding transaction in the chain. None if the funding transaction has
/// not yet been confirmed and the channel fully opened.
Expand All @@ -252,6 +259,10 @@ pub struct ChannelDetails {
/// For channels with [`confirmations_required`] set to `Some(0)`, [`outbound_scid_alias`] may
/// be used in place of this in outbound routes.
///
/// When a channel is spliced, this continues to refer to the original pre-splice channel state
/// until the splice transaction reaches sufficient confirmations to be locked (and we exchange
/// `splice_locked` messages with our peer).
///
/// [`inbound_scid_alias`]: Self::inbound_scid_alias
/// [`outbound_scid_alias`]: Self::outbound_scid_alias
/// [`confirmations_required`]: Self::confirmations_required
Expand All @@ -263,6 +274,10 @@ pub struct ChannelDetails {
///
/// This will be `None` as long as the channel is not available for routing outbound payments.
///
/// When a channel is spliced, this continues to refer to the original pre-splice channel
/// state until the splice transaction reaches sufficient confirmations to be locked (and we
/// exchange `splice_locked` messages with our peer).
///
/// [`short_channel_id`]: Self::short_channel_id
/// [`confirmations_required`]: Self::confirmations_required
pub outbound_scid_alias: Option<u64>,
Expand All @@ -277,6 +292,10 @@ pub struct ChannelDetails {
/// [`short_channel_id`]: Self::short_channel_id
pub inbound_scid_alias: Option<u64>,
/// The value, in satoshis, of this channel as it appears in the funding output.
///
/// When a channel is spliced, this continues to refer to the original pre-splice channel
/// state until the splice transaction reaches sufficient confirmations to be locked (and we
/// exchange `splice_locked` messages with our peer).
pub channel_value_sats: u64,
/// The value, in satoshis, that must always be held as a reserve in the channel for us. This
/// value ensures that if we broadcast a revoked state, our counterparty can punish us by
Expand Down
Loading