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
110 changes: 110 additions & 0 deletions src/ffi/types.rs
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +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::CounterpartyForwardingInfo;
use lightning::ln::channelmanager::PaymentId;
use lightning::ln::msgs::DecodeError;
pub use lightning::ln::types::ChannelId;
Expand All @@ -43,6 +44,7 @@ pub use lightning_liquidity::lsps0::ser::LSPSDateTime;
pub use lightning_liquidity::lsps1::msgs::{
LSPS1ChannelInfo, LSPS1OrderId, LSPS1OrderParams, LSPS1PaymentState,
};
use lightning_types::features::InitFeatures as LdkInitFeatures;
pub use lightning_types::payment::{PaymentHash, PaymentPreimage, PaymentSecret};
pub use lightning_types::string::UntrustedString;
use vss_client::headers::{
Expand Down Expand Up @@ -1496,6 +1498,114 @@ pub enum ClosureReason {
},
}

#[derive(Debug, Clone, PartialEq, Eq, uniffi::Object)]
#[uniffi::export(Debug, Eq)]
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 supports `option_static_remotekey` (bit 13).
///
/// This ensures the non-broadcaster's output pays directly to their specified key,
/// simplifying recovery if a channel is force-closed.
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?

self.inner.supports_static_remote_key()
}

/// Whether the peer supports `option_anchors_zero_fee_htlc_tx` (bit 23).
///
/// Anchor channels allow fee-bumping commitment transactions after broadcast,
/// improving on-chain fee management.
pub fn supports_anchors_zero_fee_htlc_tx(&self) -> bool {
self.inner.supports_anchors_zero_fee_htlc_tx()
}

/// Whether the peer supports `option_support_large_channel` (bit 19).
///
/// When supported, channels larger than 2^24 satoshis (≈0.168 BTC) may be opened.
pub fn supports_wumbo(&self) -> bool {
self.inner.supports_wumbo()
}

/// Whether the peer supports `option_route_blinding` (bit 25).
///
/// Route blinding allows the recipient to hide their node identity and
/// last-hop channel from the sender.
pub fn supports_route_blinding(&self) -> bool {
self.inner.supports_route_blinding()
}

/// Whether the peer supports `option_onion_messages` (bit 39).
///
/// Onion messages enable communication over the Lightning Network without
/// requiring a payment, used by BOLT 12 offers and async payments.
pub fn supports_onion_messages(&self) -> bool {
self.inner.supports_onion_messages()
}

/// Whether the peer supports `option_scid_alias` (bit 47).
///
/// When supported, the peer will only forward using short channel ID aliases,
/// preventing the real channel UTXO from being revealed during routing.
pub fn supports_scid_privacy(&self) -> bool {
self.inner.supports_scid_privacy()
}

/// Whether the peer supports `option_zeroconf` (bit 51).
///
/// Zero-conf channels can be used immediately without waiting for
/// on-chain funding confirmations.
pub fn supports_zero_conf(&self) -> bool {
self.inner.requires_zero_conf()
}

/// Whether the peer supports `option_dual_fund` (bit 29).
///
/// Dual-funded channels allow both parties to contribute funds
/// to the channel opening transaction.
pub fn supports_dual_fund(&self) -> bool {
self.inner.supports_dual_fund()
}

/// Whether the peer supports `option_quiesce` (bit 35).
///
/// Quiescence is a prerequisite for splicing, allowing both sides to
/// pause HTLC activity before modifying the funding transaction.
pub fn supports_quiescence(&self) -> bool {
self.inner.supports_quiescence()
}
}

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
10 changes: 8 additions & 2 deletions src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -176,7 +176,9 @@ use types::{
HRNResolver, KeysManager, OnionMessenger, PaymentStore, PeerManager, Router, Scorer, Sweeper,
Wallet,
};
pub use types::{ChannelDetails, CustomTlvRecord, PeerDetails, SyncAndAsyncKVStore, UserChannelId};
pub use types::{
ChannelDetails, CustomTlvRecord, PeerDetails, ReserveType, SyncAndAsyncKVStore, UserChannelId,
};
pub use vss_client;

use crate::scoring::setup_background_pathfinding_scores_sync;
Expand Down Expand Up @@ -1069,7 +1071,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
169 changes: 121 additions & 48 deletions src/types.rs
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ use bitcoin_payment_instructions::onion_message_resolver::LDKOnionMessageDNSSECH
use lightning::chain::chainmonitor;
use lightning::impl_writeable_tlv_based;
use lightning::ln::channel_state::ChannelDetails as LdkChannelDetails;
use lightning::ln::channel_state::CounterpartyForwardingInfo;
use lightning::ln::msgs::{RoutingMessageHandler, SocketAddress};
use lightning::ln::peer_handler::IgnoringMessageHandler;
use lightning::ln::types::ChannelId;
Expand All @@ -32,14 +33,20 @@ use lightning_net_tokio::SocketDescriptor;

use crate::chain::bitcoind::UtxoSourceClient;
use crate::chain::ChainSource;
use crate::config::ChannelConfig;
use crate::config::{AnchorChannelsConfig, ChannelConfig};
use crate::data_store::DataStore;
use crate::fee_estimator::OnchainFeeEstimator;
use crate::ffi::maybe_wrap;
use crate::logger::Logger;
use crate::message_handler::NodeCustomMessageHandler;
use crate::payment::{PaymentDetails, PendingPaymentDetails};
use crate::runtime::RuntimeSpawner;

#[cfg(not(feature = "uniffi"))]
type InitFeatures = lightning::types::features::InitFeatures;
#[cfg(feature = "uniffi")]
type InitFeatures = Arc<crate::ffi::InitFeatures>;

/// A supertrait that requires that a type implements both [`KVStore`] and [`KVStoreSync`] at the
/// same time.
pub trait SyncAndAsyncKVStore: KVStore + KVStoreSync {}
Expand Down Expand Up @@ -376,6 +383,75 @@ impl fmt::Display for UserChannelId {
}
}

/// Channel parameters which apply to our counterparty. These are split out from [`ChannelDetails`]
/// to better separate parameters.
#[derive(Clone, Debug, PartialEq)]
#[cfg_attr(feature = "uniffi", derive(uniffi::Record))]
pub struct ChannelCounterparty {
/// The node_id of our counterparty
pub node_id: PublicKey,
/// The Features the channel counterparty provided upon last connection.
/// Useful for routing as it is the most up-to-date copy of the counterparty's features and
/// many routing-relevant features are present in the init context.
pub features: InitFeatures,
/// The value, in satoshis, that must always be held in the channel for our counterparty. This
/// value ensures that if our counterparty broadcasts a revoked state, we can punish them by
/// claiming at least this value on chain.
///
/// This value is not included in [`inbound_capacity_msat`] as it can never be spent.
///
/// [`inbound_capacity_msat`]: ChannelDetails::inbound_capacity_msat
pub unspendable_punishment_reserve: u64,
/// Information on the fees and requirements that the counterparty requires when forwarding
/// payments to us through this channel.
pub forwarding_info: Option<CounterpartyForwardingInfo>,
/// The smallest value HTLC (in msat) the remote peer will accept, for this channel.
pub outbound_htlc_minimum_msat: u64,
/// The largest value HTLC (in msat) the remote peer currently will accept, for this channel.
pub outbound_htlc_maximum_msat: Option<u64>,
}

/// Describes the reserve behavior of a channel based on its type and trust configuration.
///
/// This captures the combination of the channel's on-chain construction (anchor outputs vs legacy
/// static_remote_key) and whether the counterparty is in our trusted peers list. It tells the
/// user what reserve obligations exist for this channel without exposing internal protocol details.
///
/// See [`AnchorChannelsConfig`] for how reserve behavior is configured.
///
/// [`AnchorChannelsConfig`]: crate::config::AnchorChannelsConfig
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
#[cfg_attr(feature = "uniffi", derive(uniffi::Enum))]
pub enum ReserveType {
/// An anchor outputs channel where we maintain a per-channel on-chain reserve for fee
/// bumping force-close transactions.
///
/// Anchor channels allow either party to fee-bump commitment transactions via CPFP
/// at broadcast time. Because the pre-signed commitment fee may be insufficient under
/// current fee conditions, the broadcaster must supply additional funds (hence adaptive)
/// through an anchor output spend. The reserve ensures sufficient on-chain funds are
/// available to cover this.
///
/// This is the default for anchor channels when the counterparty is not in
/// [`trusted_peers_no_reserve`].
///
/// [`trusted_peers_no_reserve`]: crate::config::AnchorChannelsConfig::trusted_peers_no_reserve
Adaptive,
/// An anchor outputs channel where we do not maintain any reserve, because the counterparty
/// is in our [`trusted_peers_no_reserve`] list.
///
/// In this mode, we trust the counterparty to broadcast a valid commitment transaction on
/// our behalf and do not set aside funds for fee bumping.
///
/// [`trusted_peers_no_reserve`]: crate::config::AnchorChannelsConfig::trusted_peers_no_reserve
TrustedPeersNoReserve,
/// A legacy (pre-anchor) channel using only `option_static_remotekey`.
///
/// These channels do not use anchor outputs and therefore do not require an on-chain reserve
/// for fee bumping. Commitment transaction fees are pre-committed at channel open time.
Legacy,
}

/// 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
Expand All @@ -392,8 +468,8 @@ pub struct ChannelDetails {
/// Note that this means this value is *not* persistent - it can change once during the
/// lifetime of the channel.
pub channel_id: ChannelId,
/// The node ID of our the channel's counterparty.
pub counterparty_node_id: PublicKey,
/// Parameters which apply to our counterparty. See individual fields for more information.
pub counterparty: ChannelCounterparty,
/// The channel's funding transaction output, if we've negotiated the funding transaction with
/// our counterparty already.
///
Expand Down Expand Up @@ -509,28 +585,6 @@ pub struct ChannelDetails {
/// The difference in the CLTV value between incoming HTLCs and an outbound HTLC forwarded over
/// the channel.
pub cltv_expiry_delta: Option<u16>,
/// The value, in satoshis, that must always be held in the channel for our counterparty. This
/// value ensures that if our counterparty broadcasts a revoked state, we can punish them by
/// claiming at least this value on chain.
///
/// This value is not included in [`inbound_capacity_msat`] as it can never be spent.
///
/// [`inbound_capacity_msat`]: ChannelDetails::inbound_capacity_msat
pub counterparty_unspendable_punishment_reserve: u64,
/// 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.
pub counterparty_outbound_htlc_minimum_msat: Option<u64>,
/// The largest value HTLC (in msat) the remote peer currently will accept, for this channel.
pub counterparty_outbound_htlc_maximum_msat: Option<u64>,
/// Base routing fee in millisatoshis.
pub counterparty_forwarding_info_fee_base_msat: Option<u32>,
/// Proportional fee, in millionths of a satoshi the channel will charge per transferred satoshi.
pub counterparty_forwarding_info_fee_proportional_millionths: Option<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 counterparty_forwarding_info_cltv_expiry_delta: Option<u16>,
/// 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
Expand Down Expand Up @@ -558,13 +612,51 @@ pub struct ChannelDetails {
pub inbound_htlc_maximum_msat: Option<u64>,
/// Set of configurable parameters that affect channel operation.
pub config: ChannelConfig,
/// The type of on-chain reserve maintained for this channel.
///
/// See [`ReserveType`] for details on how reserves differ between anchor and legacy channels.
pub reserve_type: ReserveType,
}

impl From<LdkChannelDetails> for ChannelDetails {
fn from(value: LdkChannelDetails) -> Self {
impl ChannelDetails {
pub(crate) fn from_ldk(
value: LdkChannelDetails, anchor_channels_config: Option<&AnchorChannelsConfig>,
) -> Self {
let reserve_type =
if value.channel_type.as_ref().is_some_and(|ct| ct.supports_anchors_zero_fee_htlc_tx())
{
if let Some(config) = anchor_channels_config {
if config.trusted_peers_no_reserve.contains(&value.counterparty.node_id) {
ReserveType::TrustedPeersNoReserve
} else {
ReserveType::Adaptive
}
} else {
// Edge case: if `AnchorChannelsConfig` was previously set and later
// removed, we can no longer distinguish whether this anchor channel's
// reserve was `Adaptive` or `TrustedPeersNoReserve`. We default to
// `Adaptive` here, which may incorrectly override a prior
// `TrustedPeersNoReserve` designation. This is acceptable since
// unsetting `AnchorChannelsConfig` on a node with existing anchor
// channels is not an expected operation.
ReserveType::Adaptive
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, isn't this wrong? I believe we'd fallback to legacy if we don't have an anchors_channel_config set?

I guess we could only land here if we had already accepted an anchor channel and then the user changed anchors_channels_config afterwards?

Might be good to at least leave some comments here to give some rationale.

Copy link
Copy Markdown
Contributor Author

@enigbe enigbe Apr 2, 2026

Choose a reason for hiding this comment

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

Good catch here. You are right that we only reach this branch if an anchor channel was previously opened with anchor_channels_config set, and then later unset. In that case, Legacy would be incorrect and Adaptive could also be wrong . The channel will still be an anchor type, but if it was originally TrustedPeersNoReserve, we'd silently reclassify it as Adaptive.

I think the main problem is that we derive the reserve_type at query time from the current config rather than recording it when the channel is opened. So any config change could cause a loss of distinction where we can't distinguish between anchor channels that were Adaptive vs TrustedPeersNoReserve.

We could explore persisting the reserve type (keyed by ChannelId) when we open a channel, and have list_channels look up the stored value instead of re-deriving it. What do you think?

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.

I'd rather not persist it. Can we just determine based on the feature, and then decide between Adaptive and TrustedPeersNoReserve based on whether or not the peer is present in the no reserve list? I guess that's kind of what we're doing already?

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.

Yeah, we already do this. There's just that one edge case where a user unsets the anchor channels config after previously setting it. We'd be able to tell if it's an anchor channel but not whether it's adaptive or not.

Copy link
Copy Markdown
Collaborator

@tnull tnull Apr 3, 2026

Choose a reason for hiding this comment

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

I guess that's fine. Could you maybe add a comment to reflect the current rationale/thinking and documenting this edge case? And then we can probably move ahead. Not sure if it's worth over-engineering this.

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.

Sure. I'll add the comment.

}
} else {
ReserveType::Legacy
};

ChannelDetails {
channel_id: value.channel_id,
counterparty_node_id: value.counterparty.node_id,
counterparty: ChannelCounterparty {
node_id: value.counterparty.node_id,
features: maybe_wrap(value.counterparty.features),
unspendable_punishment_reserve: value.counterparty.unspendable_punishment_reserve,
forwarding_info: value.counterparty.forwarding_info,
// unwrap safety: This value will be `None` for objects serialized with LDK versions
// prior to 0.0.115.
outbound_htlc_minimum_msat: value.counterparty.outbound_htlc_minimum_msat.unwrap(),
outbound_htlc_maximum_msat: value.counterparty.outbound_htlc_maximum_msat,
},
funding_txo: value.funding_txo.map(|o| o.into_bitcoin_outpoint()),
funding_redeem_script: value.funding_redeem_script,
short_channel_id: value.short_channel_id,
Expand All @@ -585,26 +677,6 @@ impl From<LdkChannelDetails> for ChannelDetails {
is_usable: value.is_usable,
is_announced: value.is_announced,
cltv_expiry_delta: value.config.map(|c| c.cltv_expiry_delta),
counterparty_unspendable_punishment_reserve: value
.counterparty
.unspendable_punishment_reserve,
counterparty_outbound_htlc_minimum_msat: value.counterparty.outbound_htlc_minimum_msat,
counterparty_outbound_htlc_maximum_msat: value.counterparty.outbound_htlc_maximum_msat,
counterparty_forwarding_info_fee_base_msat: value
.counterparty
.forwarding_info
.as_ref()
.map(|f| f.fee_base_msat),
counterparty_forwarding_info_fee_proportional_millionths: value
.counterparty
.forwarding_info
.as_ref()
.map(|f| f.fee_proportional_millionths),
counterparty_forwarding_info_cltv_expiry_delta: value
.counterparty
.forwarding_info
.as_ref()
.map(|f| f.cltv_expiry_delta),
next_outbound_htlc_limit_msat: value.next_outbound_htlc_limit_msat,
next_outbound_htlc_minimum_msat: value.next_outbound_htlc_minimum_msat,
force_close_spend_delay: value.force_close_spend_delay,
Expand All @@ -613,6 +685,7 @@ impl From<LdkChannelDetails> for ChannelDetails {
inbound_htlc_maximum_msat: value.inbound_htlc_maximum_msat,
// unwrap safety: `config` is only `None` for LDK objects serialized prior to 0.0.109.
config: value.config.map(|c| c.into()).unwrap(),
reserve_type,
}
}
}
Expand Down
Loading
Loading