Skip to content
Merged
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
8 changes: 8 additions & 0 deletions src/builder.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1090,6 +1090,14 @@ fn build_with_store_internal(
// If we act as an LSPS2 service, we need to to be able to intercept HTLCs and forward the
// information to the service handler.
user_config.accept_intercept_htlcs = true;

// If we act as an LSPS2 service, we allow forwarding to unnannounced channels.
user_config.accept_forwards_to_priv_channels = true;

// If we act as an LSPS2 service, set the HTLC-value-in-flight to 100% of the channel value
// to ensure we can forward the initial payment.
user_config.channel_handshake_config.max_inbound_htlc_value_in_flight_percent_of_channel =
100;
}

let message_router =
Expand Down
13 changes: 8 additions & 5 deletions src/liquidity.rs
Original file line number Diff line number Diff line change
Expand Up @@ -675,11 +675,14 @@ where

let mut config = *self.channel_manager.get_current_default_configuration();

// Set the HTLC-value-in-flight to 100% of the channel value to ensure we can
// forward the payment.
config
.channel_handshake_config
.max_inbound_htlc_value_in_flight_percent_of_channel = 100;
// We set these LSP-specific values during Node building, here we're making sure it's actually set.
debug_assert_eq!(
config
.channel_handshake_config
.max_inbound_htlc_value_in_flight_percent_of_channel,
100
);
debug_assert!(config.accept_forwards_to_priv_channels);
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems quite defensive. Is it really needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yup, in this case I'd prefer to make sure it is set. The issue is that we have 2-3 UserConfigs flying around now that we change depending on the context/assumptions. This is just insurance going forward that we don't change something somewhere else without keeping this use case in mind. Maybe at some point it might warrant a refactoring with some more involved config management, but I think we're not entirely there yet.


// We set the forwarding fee to 0 for now as we're getting paid by the channel fee.
//
Expand Down
16 changes: 16 additions & 0 deletions tests/integration_tests_rust.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1145,6 +1145,22 @@ fn lsps2_client_service_integration() {
(expected_received_amount_msat + expected_channel_overprovisioning_msat) / 1000;
let channel_value_sats = client_node.list_channels().first().unwrap().channel_value_sats;
assert_eq!(channel_value_sats, expected_channel_size_sat);

println!("Generating regular invoice!");
let invoice_description =
Bolt11InvoiceDescription::Direct(Description::new(String::from("asdf")).unwrap());
let amount_msat = 5_000_000;
let invoice = client_node
.bolt11_payment()
.receive(amount_msat, &invoice_description.into(), 1024)
.unwrap();

// Have the payer_node pay the invoice, to check regular forwards service_node -> client_node
// are working as expected.
println!("Paying regular invoice!");
let payment_id = payer_node.bolt11_payment().send(&invoice, None).unwrap();
expect_payment_successful_event!(payer_node, Some(payment_id), None);
expect_payment_received_event!(client_node, amount_msat);
}

#[test]
Expand Down
Loading