Skip to content

Commit 1dd3988

Browse files
Add enable_htlc_hold cfg flag + fail hold htlcs
As part of supporting sending payments as an often-offline sender, the often-offline sender's channel counterparty needs to advertise a feature bit indicating that they support holding onto the sender's HTLC until they receive a release_held_htlc onion message from the recipient indicating that they are online and ready to receive the payment. Here we add a config flag to turn on advertising this feature, and fail back hold_htlcs if this config flag is not set. See-also <lightning/bolts#989>
1 parent 44d21c9 commit 1dd3988

File tree

2 files changed

+47
-0
lines changed

2 files changed

+47
-0
lines changed

lightning/src/ln/channelmanager.rs

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6420,6 +6420,32 @@ where
64206420
});
64216421
let shared_secret = next_hop.shared_secret().secret_bytes();
64226422

6423+
// Nodes shouldn't expect us to hold HTLCs for them if we don't advertise htlc_hold feature
6424+
// support.
6425+
//
6426+
// If we wanted to pretend to be a node that didn't understand the feature at all here, the
6427+
// correct behavior would've been to disconnect the sender when we first received the
6428+
// update_add message. However, this would make the `UserConfig::enable_htlc_hold` option
6429+
// unsafe -- if our node switched the config option from on to off just after the sender
6430+
// enqueued their update_add + CS, the sender would continue retransmitting those messages
6431+
// and we would keep disconnecting them until the HTLC timed out.
6432+
if update_add_htlc.hold_htlc.is_some()
6433+
&& !BaseMessageHandler::provided_node_features(self).supports_htlc_hold()
6434+
{
6435+
let reason = LocalHTLCFailureReason::TemporaryNodeFailure;
6436+
let htlc_fail = self.htlc_failure_from_update_add_err(
6437+
&update_add_htlc,
6438+
&incoming_counterparty_node_id,
6439+
reason,
6440+
is_intro_node_blinded_forward,
6441+
&shared_secret,
6442+
);
6443+
let failure_type =
6444+
get_htlc_failure_type(outgoing_scid_opt, update_add_htlc.payment_hash);
6445+
htlc_fails.push((htlc_fail, failure_type, reason.into()));
6446+
continue;
6447+
}
6448+
64236449
// Process the HTLC on the incoming channel.
64246450
match self.do_funded_channel_callback(
64256451
incoming_scid,
@@ -14847,6 +14873,13 @@ pub fn provided_init_features(config: &UserConfig) -> InitFeatures {
1484714873
features.set_anchor_zero_fee_commitments_optional();
1484814874
}
1484914875

14876+
// If we are configured to be an announced node, we are expected to be always-online and can
14877+
// advertise the htlc_hold feature.
14878+
#[cfg(test)]
14879+
if config.enable_htlc_hold {
14880+
features.set_htlc_hold_optional();
14881+
}
14882+
1485014883
features
1485114884
}
1485214885

lightning/src/util/config.rs

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -935,6 +935,18 @@ pub struct UserConfig {
935935
///
936936
/// Default value: `false`
937937
pub enable_dual_funded_channels: bool,
938+
/// LDK supports a feature for always-online nodes such that these nodes can hold onto an HTLC
939+
/// from an often-offline channel peer until the often-offline payment recipient sends an onion
940+
/// message telling the always-online node to release the HTLC. If this is set to `true`, our node
941+
/// will carry out this feature for channel peers that request it.
942+
///
943+
/// This should only be set to `true` for nodes which expect to be online reliably.
944+
///
945+
/// Setting this to `true` may break backwards compatibility with LDK versions < 0.2.
946+
///
947+
/// Default value: `false`
948+
#[cfg(test)]
949+
pub enable_htlc_hold: bool,
938950
}
939951

940952
impl Default for UserConfig {
@@ -949,6 +961,8 @@ impl Default for UserConfig {
949961
accept_intercept_htlcs: false,
950962
manually_handle_bolt12_invoices: false,
951963
enable_dual_funded_channels: false,
964+
#[cfg(test)]
965+
enable_htlc_hold: false,
952966
}
953967
}
954968
}

0 commit comments

Comments
 (0)