Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
294 changes: 292 additions & 2 deletions src/ffi/types.rs
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ pub use bitcoin::{Address, BlockHash, Network, OutPoint, ScriptBuf, Txid};
pub use lightning::chain::channelmonitor::BalanceSource;
use lightning::events::PaidBolt12Invoice as LdkPaidBolt12Invoice;
pub use lightning::events::{ClosureReason, PaymentFailureReason};
use lightning::ln::channel_state::ChannelShutdownState;
use lightning::ln::channel_state::{ChannelShutdownState, CounterpartyForwardingInfo};
use lightning::ln::channelmanager::PaymentId;
use lightning::ln::msgs::DecodeError;
pub use lightning::ln::types::ChannelId;
Expand All @@ -44,7 +44,7 @@ pub use lightning_liquidity::lsps0::ser::LSPSDateTime;
pub use lightning_liquidity::lsps1::msgs::{
LSPS1ChannelInfo, LSPS1OrderId, LSPS1OrderParams, LSPS1PaymentState,
};
use lightning_types::features::NodeFeatures as LdkNodeFeatures;
use lightning_types::features::{InitFeatures as LdkInitFeatures, NodeFeatures as LdkNodeFeatures};
pub use lightning_types::payment::{PaymentHash, PaymentPreimage, PaymentSecret};
pub use lightning_types::string::UntrustedString;
use vss_client::headers::{
Expand Down Expand Up @@ -1815,6 +1815,296 @@ impl From<LdkNodeFeatures> for NodeFeatures {
}
}

#[derive(Debug, Clone, PartialEq, Eq, uniffi::Object)]
pub struct InitFeatures {
pub(crate) inner: LdkInitFeatures,
}

impl InitFeatures {
/// Constructs init features from big-endian BOLT 9 encoded bytes.
#[uniffi::constructor]
pub fn from_bytes(bytes: &[u8]) -> Self {
Self { inner: LdkInitFeatures::from_be_bytes(bytes.to_vec()).into() }
}

/// Returns the BOLT 9 big-endian encoded representation of these features.
pub fn to_bytes(&self) -> Vec<u8> {
self.inner.encode()
}

/// Whether the peer's `init` message advertises support for `option_static_remotekey`.
pub fn supports_static_remote_key(&self) -> bool {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

It seems we're missing a bunch of features here? E.g. supports_keysend and others seem to be missing?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I've added the missing features but support_keysend applies to NodeFeatures only.

self.inner.supports_static_remote_key()
}

/// Whether the peer's `init` message requires `option_static_remotekey`.
pub fn requires_static_remote_key(&self) -> bool {
self.inner.requires_static_remote_key()
}

/// Whether the peer's `init` message advertises support for `option_anchors_zero_fee_htlc_tx`.
pub fn supports_anchors_zero_fee_htlc_tx(&self) -> bool {
self.inner.supports_anchors_zero_fee_htlc_tx()
}

/// Whether the peer's `init` message requires `option_anchors_zero_fee_htlc_tx`.
pub fn requires_anchors_zero_fee_htlc_tx(&self) -> bool {
self.inner.requires_anchors_zero_fee_htlc_tx()
}

/// Whether the peer's `init` message advertises support for `option_anchors_nonzero_fee_htlc_tx`.
pub fn supports_anchors_nonzero_fee_htlc_tx(&self) -> bool {
self.inner.supports_anchors_nonzero_fee_htlc_tx()
}

/// Whether the peer's `init` message requires `option_anchors_nonzero_fee_htlc_tx`.
pub fn requires_anchors_nonzero_fee_htlc_tx(&self) -> bool {
self.inner.requires_anchors_nonzero_fee_htlc_tx()
}

/// Whether the peer's `init` message advertises support for `option_support_large_channel`.
pub fn supports_wumbo(&self) -> bool {
self.inner.supports_wumbo()
}

/// Whether the peer's `init` message requires `option_support_large_channel`.
pub fn requires_wumbo(&self) -> bool {
self.inner.requires_wumbo()
}

/// Whether the peer's `init` message advertises support for `option_route_blinding`.
pub fn supports_route_blinding(&self) -> bool {
self.inner.supports_route_blinding()
}

/// Whether the peer's `init` message requires `option_route_blinding`.
pub fn requires_route_blinding(&self) -> bool {
self.inner.requires_route_blinding()
}

/// Whether the peer's `init` message advertises support for `option_onion_messages`.
pub fn supports_onion_messages(&self) -> bool {
self.inner.supports_onion_messages()
}

/// Whether the peer's `init` message requires `option_onion_messages`.
pub fn requires_onion_messages(&self) -> bool {
self.inner.requires_onion_messages()
}

/// Whether the peer's `init` message advertises support for `option_scid_alias`.
pub fn supports_scid_privacy(&self) -> bool {
self.inner.supports_scid_privacy()
}

/// Whether the peer's `init` message requires `option_scid_alias`.
pub fn requires_scid_privacy(&self) -> bool {
self.inner.requires_scid_privacy()
}

/// Whether the peer's `init` message advertises support for `option_zeroconf`.
pub fn supports_zero_conf(&self) -> bool {
self.inner.supports_zero_conf()
}

/// Whether the peer's `init` message requires `option_zeroconf`.
pub fn requires_zero_conf(&self) -> bool {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Hmm, this seems to be the only required_ variant we're exposing. Is this intentional?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, intentional. In rust-lightning, supports_zero_conf actually clears the feature, while requires_zero_conf checks whether zero-conf is supported. I kept the upstream naming for parity, even though it’s admittedly confusing.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Yes, intentional. In rust-lightning, supports_zero_conf actually clears the feature

Not sure I understand what you mean by that? Are you referring to this recently-fixed bug? lightningdevkit/rust-lightning#4517

Generally, requiring and supporting a feature are two different things (cf https://github.com/lightning/bolts/blob/master/09-features.md) and we should expose both APIs whenever we can. IIRC, zero conf might be the only (?) exception as it's always deemed required if it's set.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Not sure I understand what you mean by that? Are you referring to this recently-fixed bug? lightningdevkit/rust-lightning#4517

I wasn't aware this was a bug. Due to the macro misalignment, requires_zero_conf currently maps to $supported_getter, so it actually checks support rather than requirement. I can either open a separate PR to bump rust-lightning to lightningdevkit/rust-lightning@47122e8, or include a drop-me commit in this PR that updates the revision to one with the fix, which gets cleaned up when rebasing on a planned rust-lightning bump. Which would you prefer?

Generally, requiring and supporting a feature are two different things (cf https://github.com/lightning/bolts/blob/master/09-features.md) and we should expose both APIs whenever we can. IIRC, zero conf might be the only (?) exception as it's always deemed required if it's set.

Thanks for clarifying. The APIs exposed so far only cover supports_* variants. I'll add those for the required features?

Copy link
Copy Markdown
Collaborator

@tnull tnull Apr 27, 2026

Choose a reason for hiding this comment

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

or include a drop-me commit in this PR that updates the revision to one with the fix, which gets cleaned up when rebasing on a planned rust-lightning bump. Which would you prefer?

Yeah, let's do that!

Thanks for clarifying. The APIs exposed so far only cover supports_* variants. I'll add those for the required features?

Yes please, would be good to offer users the capability to discern what features are optional, and which are required.

self.inner.requires_zero_conf()
}

/// Whether the peer's `init` message advertises support for `option_dual_fund`.
pub fn supports_dual_fund(&self) -> bool {
self.inner.supports_dual_fund()
}

/// Whether the peer's `init` message requires `option_dual_fund`.
pub fn requires_dual_fund(&self) -> bool {
self.inner.requires_dual_fund()
}

/// Whether the peer's `init` message advertises support for `option_quiesce`.
pub fn supports_quiescence(&self) -> bool {
self.inner.supports_quiescence()
}

/// Whether the peer's `init` message requires `option_quiesce`.
pub fn requires_quiescence(&self) -> bool {
self.inner.requires_quiescence()
}

/// Whether the peer's `init` message advertises support for `option_data_loss_protect`.
pub fn supports_data_loss_protect(&self) -> bool {
self.inner.supports_data_loss_protect()
}

/// Whether the peer's `init` message requires `option_data_loss_protect`.
pub fn requires_data_loss_protect(&self) -> bool {
self.inner.requires_data_loss_protect()
}

/// Whether the peer's `init` message advertises support for `option_upfront_shutdown_script`.
pub fn supports_upfront_shutdown_script(&self) -> bool {
self.inner.supports_upfront_shutdown_script()
}

/// Whether the peer's `init` message requires `option_upfront_shutdown_script`.
pub fn requires_upfront_shutdown_script(&self) -> bool {
self.inner.requires_upfront_shutdown_script()
}

/// Whether the peer's `init` message advertises support for `gossip_queries`.
pub fn supports_gossip_queries(&self) -> bool {
self.inner.supports_gossip_queries()
}

/// Whether the peer's `init` message requires `gossip_queries`.
pub fn requires_gossip_queries(&self) -> bool {
self.inner.requires_gossip_queries()
}

/// Whether the peer's `init` message advertises support for `var_onion_optin`.
pub fn supports_variable_length_onion(&self) -> bool {
self.inner.supports_variable_length_onion()
}

/// Whether the peer's `init` message requires `var_onion_optin`.
pub fn requires_variable_length_onion(&self) -> bool {
self.inner.requires_variable_length_onion()
}

/// Whether the peer's `init` message advertises support for `payment_secret`.
pub fn supports_payment_secret(&self) -> bool {
self.inner.supports_payment_secret()
}

/// Whether the peer's `init` message requires `payment_secret`.
pub fn requires_payment_secret(&self) -> bool {
self.inner.requires_payment_secret()
}

/// Whether the peer's `init` message advertises support for `basic_mpp`.
pub fn supports_basic_mpp(&self) -> bool {
self.inner.supports_basic_mpp()
}

/// Whether the peer's `init` message requires `basic_mpp`.
pub fn requires_basic_mpp(&self) -> bool {
self.inner.requires_basic_mpp()
}

/// Whether the peer's `init` message advertises support for `opt_shutdown_anysegwit`.
pub fn supports_shutdown_anysegwit(&self) -> bool {
self.inner.supports_shutdown_anysegwit()
}

/// Whether the peer's `init` message requires `opt_shutdown_anysegwit`.
pub fn requires_shutdown_anysegwit(&self) -> bool {
self.inner.requires_shutdown_anysegwit()
}

/// Whether the peer's `init` message advertises support for `option_channel_type`.
pub fn supports_channel_type(&self) -> bool {
self.inner.supports_channel_type()
}

/// Whether the peer's `init` message requires `option_channel_type`.
pub fn requires_channel_type(&self) -> bool {
self.inner.requires_channel_type()
}

/// Whether the peer's `init` message advertises support for `option_trampoline`.
pub fn supports_trampoline_routing(&self) -> bool {
self.inner.supports_trampoline_routing()
}

/// Whether the peer's `init` message requires `option_trampoline`.
pub fn requires_trampoline_routing(&self) -> bool {
self.inner.requires_trampoline_routing()
}

/// Whether the peer's `init` message advertises support for `option_simple_close`.
pub fn supports_simple_close(&self) -> bool {
self.inner.supports_simple_close()
}

/// Whether the peer's `init` message requires `option_simple_close`.
pub fn requires_simple_close(&self) -> bool {
self.inner.requires_simple_close()
}

/// Whether the peer's `init` message advertises support for `option_splice`.
pub fn supports_splicing(&self) -> bool {
self.inner.supports_splicing()
}

/// Whether the peer's `init` message requires `option_splice`.
pub fn requires_splicing(&self) -> bool {
self.inner.requires_splicing()
}

/// Whether the peer's `init` message advertises support for `option_provide_storage`.
pub fn supports_provide_storage(&self) -> bool {
self.inner.supports_provide_storage()
}

/// Whether the peer's `init` message requires `option_provide_storage`.
pub fn requires_provide_storage(&self) -> bool {
self.inner.requires_provide_storage()
}

/// Whether the peer's `init` message set `initial_routing_sync`.
pub fn initial_routing_sync(&self) -> bool {
self.inner.initial_routing_sync()
}

/// Whether the peer's `init` message advertises support for `option_taproot`.
pub fn supports_taproot(&self) -> bool {
self.inner.supports_taproot()
}

/// Whether the peer's `init` message requires `option_taproot`.
pub fn requires_taproot(&self) -> bool {
self.inner.requires_taproot()
}

/// Whether the peer's `init` message advertises support for `option_zero_fee_commitments`.
pub fn supports_anchor_zero_fee_commitments(&self) -> bool {
self.inner.supports_anchor_zero_fee_commitments()
}

/// Whether the peer's `init` message requires `option_zero_fee_commitments`.
pub fn requires_anchor_zero_fee_commitments(&self) -> bool {
self.inner.requires_anchor_zero_fee_commitments()
}

/// Whether the peer's `init` message advertises support for HTLC hold.
pub fn supports_htlc_hold(&self) -> bool {
self.inner.supports_htlc_hold()
}

/// Whether the peer's `init` message requires HTLC hold.
pub fn requires_htlc_hold(&self) -> bool {
self.inner.requires_htlc_hold()
}
}

impl From<LdkInitFeatures> for InitFeatures {
fn from(ldk_init: LdkInitFeatures) -> Self {
Self { inner: ldk_init }
}
}
/// Information needed for constructing an invoice route hint for this channel.
#[uniffi::remote(Record)]
pub struct CounterpartyForwardingInfo {
/// Base routing fee in millisatoshis.
pub fee_base_msat: u32,
/// Amount in millionths of a satoshi the channel will charge per transferred satoshi.
pub fee_proportional_millionths: u32,
/// The minimum difference in cltv_expiry between an ingoing HTLC and its outgoing counterpart,
/// such that the outgoing HTLC is forwardable to this counterparty.
pub cltv_expiry_delta: u16,
}

#[cfg(test)]
mod tests {
use std::num::NonZeroU64;
Expand Down
11 changes: 9 additions & 2 deletions src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -180,7 +180,10 @@ use types::{
HRNResolver, KeysManager, OnionMessenger, PaymentStore, PeerManager, Router, Scorer, Sweeper,
Wallet,
};
pub use types::{ChannelDetails, CustomTlvRecord, PeerDetails, SyncAndAsyncKVStore, UserChannelId};
pub use types::{
ChannelCounterparty, ChannelDetails, CustomTlvRecord, PeerDetails, ReserveType,
SyncAndAsyncKVStore, UserChannelId,
};
pub use vss_client;

use crate::scoring::setup_background_pathfinding_scores_sync;
Expand Down Expand Up @@ -1093,7 +1096,11 @@ impl Node {

/// Retrieve a list of known channels.
pub fn list_channels(&self) -> Vec<ChannelDetails> {
self.channel_manager.list_channels().into_iter().map(|c| c.into()).collect()
self.channel_manager
.list_channels()
.into_iter()
.map(|c| ChannelDetails::from_ldk(c, self.config.anchor_channels_config.as_ref()))
.collect()
}

/// Connect to a node on the peer-to-peer network.
Expand Down
Loading