Update `ChannelDetails` docs for splicing by tnull · Pull Request #721 · lightningdevkit/ldk-node

tnull · 2025-12-01T09:25:14Z

This simply adopts the changes of rust-lightning#4250.

ldk-reviews-bot · 2025-12-01T09:25:17Z

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

valentinewallace · 2025-12-01T18:14:16Z

+///
 /// [`Node::list_channels`]: crate::Node::list_channels
 #[derive(Debug, Clone)]
 pub struct ChannelDetails {


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

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.

Ah, got it. Thanks for that explanation!

…nel-details-docs Update `ChannelDetails` docs for splicing

tnull · 2025-12-01T09:25:14Z

This simply adopts the changes of rust-lightning#4250.

ldk-reviews-bot · 2025-12-01T09:25:17Z

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

valentinewallace · 2025-12-01T18:14:16Z

+///
 /// [`Node::list_channels`]: crate::Node::list_channels
 #[derive(Debug, Clone)]
 pub struct ChannelDetails {


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

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.

Ah, got it. Thanks for that explanation!

…nel-details-docs Update `ChannelDetails` docs for splicing

tnull · 2025-12-01T09:25:14Z

This simply adopts the changes of rust-lightning#4250.

ldk-reviews-bot · 2025-12-01T09:25:17Z

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

valentinewallace · 2025-12-01T18:14:16Z

+///
 /// [`Node::list_channels`]: crate::Node::list_channels
 #[derive(Debug, Clone)]
 pub struct ChannelDetails {


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

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.

Ah, got it. Thanks for that explanation!

…nel-details-docs Update `ChannelDetails` docs for splicing

tnull · 2025-12-01T09:25:14Z

This simply adopts the changes of rust-lightning#4250.

ldk-reviews-bot · 2025-12-01T09:25:17Z

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

valentinewallace · 2025-12-01T18:14:16Z

+///
 /// [`Node::list_channels`]: crate::Node::list_channels
 #[derive(Debug, Clone)]
 pub struct ChannelDetails {


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

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.

Ah, got it. Thanks for that explanation!

…nel-details-docs Update `ChannelDetails` docs for splicing

tnull · 2025-12-01T09:25:14Z

This simply adopts the changes of rust-lightning#4250.

ldk-reviews-bot · 2025-12-01T09:25:17Z

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

valentinewallace · 2025-12-01T18:14:16Z

+///
 /// [`Node::list_channels`]: crate::Node::list_channels
 #[derive(Debug, Clone)]
 pub struct ChannelDetails {


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

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.

Ah, got it. Thanks for that explanation!

…nel-details-docs Update `ChannelDetails` docs for splicing

tnull · 2025-12-01T09:25:14Z

This simply adopts the changes of rust-lightning#4250.

ldk-reviews-bot · 2025-12-01T09:25:17Z

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

valentinewallace · 2025-12-01T18:14:16Z

+///
 /// [`Node::list_channels`]: crate::Node::list_channels
 #[derive(Debug, Clone)]
 pub struct ChannelDetails {


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

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.

Ah, got it. Thanks for that explanation!

…nel-details-docs Update `ChannelDetails` docs for splicing

tnull · 2025-12-01T09:25:14Z

This simply adopts the changes of rust-lightning#4250.

ldk-reviews-bot · 2025-12-01T09:25:17Z

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

valentinewallace · 2025-12-01T18:14:16Z

+///
 /// [`Node::list_channels`]: crate::Node::list_channels
 #[derive(Debug, Clone)]
 pub struct ChannelDetails {


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

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.

Ah, got it. Thanks for that explanation!

…nel-details-docs Update `ChannelDetails` docs for splicing

tnull · 2025-12-01T09:25:14Z

This simply adopts the changes of rust-lightning#4250.

ldk-reviews-bot · 2025-12-01T09:25:17Z

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

valentinewallace · 2025-12-01T18:14:16Z

+///
 /// [`Node::list_channels`]: crate::Node::list_channels
 #[derive(Debug, Clone)]
 pub struct ChannelDetails {


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

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.

Ah, got it. Thanks for that explanation!

…nel-details-docs Update `ChannelDetails` docs for splicing

Update ChannelDetails docs for splicing
d231642
This simply adopts the changes of rust-lightning#4250.

tnull mentioned this pull request Dec 1, 2025
Update docs for ChannelDetails fields which change on splice lightningdevkit/rust-lightning#4250
Merged

ldk-reviews-bot requested a review from valentinewallace December 1, 2025 09:35

valentinewallace approved these changes Dec 1, 2025
View reviewed changes

tnull merged commit 650fd19 into lightningdevkit:mainDec 2, 2025
12 of 18 checks passed

kaloudis pushed a commit to ZeusLN/ldk-node that referenced this pull request Apr 6, 2026
Merge pull requestlightningdevkit#721from tnull/2025-12-update-chan…
c364d48
…nel-details-docs Update `ChannelDetails` docs for splicing