Expose ChannelCounterparty and ReserveType in ChannelDetails#841
Open
enigbe wants to merge 2 commits intolightningdevkit:mainfrom
Open
Expose ChannelCounterparty and ReserveType in ChannelDetails#841enigbe wants to merge 2 commits intolightningdevkit:mainfrom
enigbe wants to merge 2 commits intolightningdevkit:mainfrom
Conversation
We previously flattened ChannelCounterparty fields into ChannelDetails as individual counterparty_* fields, and InitFeatures was entirely omitted. This made it impossible for consumers to access per-peer feature flags, and awkward to access counterparty forwarding information without navigating the flattened field names. This commit replaces the flattened fields with a structured ChannelCounterparty type that mirrors LDK's ChannelCounterparty, exposing InitFeatures and CounterpartyForwardingInfo that were previously inaccessible. Breaking change!
We expose the reserve type of each channel through a new ReserveType enum on ChannelDetails. This tells users whether a channel uses adaptive anchor reserves, has no reserve due to a trusted peer, or is a legacy pre-anchor channel. The reserve type is derived at query time in list_channels by checking the channel's type features against trusted_peers_no_reserve. Additionally, We replace the From<LdkChannelDetails> impl with an explicit from_ldk method that takes the anchor channels config.
|
I've assigned @tnull as a reviewer! |
enigbe
added a commit
to enigbe/ldk-node
that referenced
this pull request
Mar 24, 2026
This fixup moves node feature exposure from freestanding APIs to NodeStatus, as suggested in review. Rather than exposing init_features(), channel_features(), bolt11_invoice_features(), and node_features() as separate public methods on Node, this embeds NodeFeatures in the NodeStatus struct returned by Node::status(). Additionally, channel and invoice features at node level are confusing. Users would expect negotiated per-peer/channel/invoice features, not what the node generally supports. Access to negotiated features are addressed in lightningdevkit#841
tnull
reviewed
Mar 25, 2026
Collaborator
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
Thanks! Looks pretty good, have a few initial comments.
| } | ||
| } | ||
|
|
||
| /// Information needed for constructing an invoice route hint for this channel. |
Collaborator
There was a problem hiding this comment.
Everything related to uniffi should live in ffi/types.rs, which also avoids the feature-gate on individual items.
| uniffi::custom_type!(InitFeatures, Vec<u8>, { | ||
| remote, | ||
| try_lift: |val| Ok(InitFeatures::from_le_bytes(val)), | ||
| lower: |obj| obj.le_flags().to_vec(), |
Collaborator
There was a problem hiding this comment.
Generally not the biggest fan of exposing this as Vec<u8>, but if we do, why pick little endian over big endian?
| pub forwarding_info: Option<CounterpartyForwardingInfo>, | ||
| /// The smallest value HTLC (in msat) the remote peer will accept, for this channel. This field | ||
| /// is only `None` before we have received either the `OpenChannel` or `AcceptChannel` message | ||
| /// from the remote peer, or for `ChannelCounterparty` objects serialized prior to LDK 0.0.107. |
Collaborator
There was a problem hiding this comment.
All compatibility notes should be formulated referencing LDK Node releases, not LDK releases.
| value.channel_type.as_ref().map_or(false, |ct| ct.supports_anchors_zero_fee_htlc_tx()); | ||
|
|
||
| let reserve_type = if is_anchor_channel { | ||
| let is_trusted = anchor_channels_config.map_or(false, |c| { |
Collaborator
There was a problem hiding this comment.
nit: If we use if let Some(anchors_channels_config) = once, we avoid map_oring every time and can drop the bool, etc.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
In #305, we needed a way to expose channel type and the channel reserve without leaking implementation details not useful to users. The related discussion in #141 proposed a
ReserveTypeabstraction that bakes in both in a user-relevant way. This PR introduces the said enumeration toChannelDetailswith the following variants:Legacy: signifying pre-anchor channel types where on-chain fees paying for broadcast transactions following channel closure were pre-determinedTrustedPeersNoReserve: for anchor type channels with trusted peersAdaptive: indicating anchor channel with adaptive reserve, reflecting dynamic best-effort attempt at fee-bumping.(see @jkczyz's suggestion)
We modify the
ChannelDetailsconstructor to accept an optional anchor channels config to address the challenge of users cross-referencing the channel details and config to determine if counterparties are trusted.Additionally, following recommendation in #810 about negotiated features, this PR exposes per-peer
InitFeatures, and as a consequence, modifiesChannelDetailsby replacing the flattenedcounterparty_*withChannelCounterpartythat encapsulates them and mirror LDK's.Issue Addressed
Closes #305.
Builds on discussions and recommendations from #141 and #810.