Support client_trusts_lsp on LSPS2 #3838

martinsaposnic · 2025-06-09T19:15:30Z

The feature

Currently, our LSPS2 service implementation only supports the lsp_trusts_client model, which means that "If the client does not claim the payment, and the funding transaction confirms, then the LSP will have its funds locked in a channel that was not paid for."

On a client_trusts_lsp model, the LSP will NOT broadcast the funding transaction until the client claims the payment.

The plan:

(This plan was validated and acknowledged by @tnull in private). There are differences between the plan and the implementation, but it roughly describes the approach.

LSPS2 Process & Events: These are handled the same way as before. No changes here.
When the OpenChannel event is emitted, ldk-node calls create_channel as usual. The key difference is: If client_trusts_lsp = true, after emitting the OpenChannel event, we start tracking the HTLC that our client will eventually claim.
Funding Transaction Broadcast Logic: The batch_funding_transaction_generated_intern function decides whether the funding transaction should be broadcast automatically. There are two existing funding types:
- Checked: Validates and auto-broadcasts.
- Unchecked: Skips validation and requires manual broadcast.
I will introduce a third type:
- CheckedManualBroadcast: Validates, but sets manual broadcast.
With this:
- If client_trusts_lsp = false, ldk-node uses funding_transaction_generated (default behavior).
- If client_trusts_lsp = true, it uses funding_transaction_generated_with_delayed_broadcast, which sets the funding type to CheckedManualBroadcast (validates but sets manual broadcast).
lsps2_service on ldk-node will now interact with lsps2_service on rust-lightning in two new key moments:
- When it receives the FundingTxBroadcastSafe event, it notifies lsps2_service on rust-lightning, which marks a flag as true.
- When the client claims the HTLC (::PaymentClaimed), ldk-node notifies lsps2_service on rust-lightning, which marks another flag as true.
- Once both flags are true, we are ok to proceed to broadcast the funding transaction.

Changes:

a new FundingType called CheckedManualBroadcast, which behaves the same as the FundingType::Checked, but it returns false when is_manual_broadcast is called. Essentially, it validates everything (same as the FundingType::Checked) but it does not automatically broadcast (same as FundingType::Unchecked)
new public function funding_transaction_generated_manual_broadcast on channel_manager. Uses FundingType::CheckedManualBroadcast, which validates but does not automatically broadcast
new public function channel_needs_manual_broadcast. This is used by ldk-node to know if funding_transaction_generated or funding_transaction_generated_manual_broadcast should be called when FundingGenerationReady event is triggered
new public function store_funding_transaction. This is used by ldk-node when the funding transaction is created. We need to store it because the broadcast of the funding transaction may be deferred.
new public function funding_tx_broadcast_safe. This is used by ldk-node when the FundingTxBroadcastSafe event is triggered
a new enum TrustModel is introduced, which depending on the trust model that the user chose, it will have a few properties to track:
- if the client claimed the htlc,
- the status of funding_tx_broadcast_safe.
- hold the funding_tx for later use
This new TrustModel enum will be created when the OpenChannel is triggered, and will be saved in the OutboundJITChannelState
Every time the TrustModel changes values, the function broadcast_transaction_if_applies is called, so it checks if it's time to broadcast the funding transaction
An unsafe_broadcast_transaction function is also introduced on channel_manager, which will be called by broadcast_transaction_if_applies from the lsps2/service

LDK Node integration

In this PR lightningdevkit/ldk-node#572 on ldk-node, you can see that 2 tests are created that demonstrates the funcionality described above.

First test:

client_trusts_lsp=true

In the test, receive_via_jit_channel_manual_claim is called, the mempool is checked to assert that the funding transaction was not broadcasted yet (it should not because client_trusts_lsp=true, and the client has not claimed the htlc yet).

Then the client calls claim_for_hash, and the mempool is checked again, and now the funding transaction should be there

Second test:

client_trusts_lsp=false

In the test, receive_via_jit_channel_manual_claim is called, the mempool is checked to assert that the funding transaction was broadcasted (because the LSP trusts the client), even though the client has not claimed the htlc yet. In this case, the LSP was tricked, and it will have its funds locked in a channel that was not paid for.

Side note: for the tests to work I had to create a new receive_via_jit_channel_manual_claim so the client can manually claim the htlc using the claim_for_hash.

ldk-reviews-bot · 2025-06-09T19:15:32Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-06-09T19:24:33Z

Codecov Report

❌ Patch coverage is 85.97122% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.77%. Comparing base (5b6b691) to head (90ea0f8).

Files with missing lines	Patch %	Lines
lightning-liquidity/src/lsps2/service.rs	84.52%	37 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3838      +/-   ##
==========================================
+ Coverage   88.73%   88.77%   +0.04%     
==========================================
  Files         176      176              
  Lines      129042   129298     +256     
  Branches   129042   129298     +256     
==========================================
+ Hits       114501   114781     +280     
+ Misses      11939    11917      -22     
+ Partials     2602     2600       -2

Flag	Coverage Δ
fuzzing	`22.28% <6.79%> (+0.36%)`	⬆️
tests	`88.60% <85.97%> (+0.04%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

martinsaposnic · 2025-06-09T19:59:36Z

A few extra concerns:

HTLCs routed over 0-conf channels might hit CLTV timeouts if the channel should be confirmed but isn’t yet, so if the user takes forever to claim the payment, then there could be some trouble there.

Also, I'm not sure if it would be better to have new possible states to explicitly model the idea of having sent the channel_ready but the funding_tx is not broadcasted yet. Also sharing the trust_model state between 4 of the 5 possible states is not something I'm convinced. I have a few different options for this, but I'm open to comments and suggestions

ldk-reviews-bot · 2025-06-11T19:18:30Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-14T00:00:15Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-16T00:01:10Z

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-18T00:01:36Z

🔔 4th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-21T00:00:21Z

🔔 5th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-23T00:00:54Z

🔔 6th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-25T00:01:53Z

🔔 7th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Thanks for looking into this.

This generally makes sense to me, although we should really work out how we'd deal with operational channels for which we withhold the funding transaction broadcast.

HTLCs routed over 0-conf channels might hit CLTV timeouts if the channel should be > confirmed but isn’t yet, so if the user takes forever to claim the payment, then there
could be some trouble there.

Yes. IMO this means that we need to introduce proper (read: clean API, and tested) support for 'hosted channels', i.e., channels that are operational even though the funding transaction hasn't been confirmed yet. Not sure if @TheBlueMatt has an opinion here?

Also, I'm not sure if it would be better to have new possible states to explicitly model > the idea of having sent the channel_ready but the funding_tx is not broadcasted yet. > Also sharing the trust_model state between 4 of the 5 possible states is not > something I'm convinced. I have a few different options for this, but I'm open to > comments and suggestions

Yeah, as mentioned in the comments, it would def. be preferable if we could avoid the many clones. Also it's overall a lot of boilerplate for just three fields handed through, maybe there is a simpler approach?

tnull · 2025-06-26T11:30:11Z

lightning-liquidity/src/lsps2/service.rs

@@ -11,6 +11,7 @@

 use alloc::string::{String, ToString};
 use alloc::vec::Vec;
+use bitcoin::Transaction;


nit: Let's move this down to the other bitcoin types.

tnull · 2025-06-26T11:31:24Z

lightning-liquidity/src/lsps2/service.rs

+			TrustModel::ClientTrustsLsp { funding_tx_broadcast_safe, htlc_claimed, funding_tx } => {
+				*funding_tx_broadcast_safe && *htlc_claimed && funding_tx.is_some()
+			},
+			TrustModel::LspTrustsClient => false,


Shouldn't this always be true?

actually the method name is confusing. this should be false because in lsp-trusts-client, the broadcast is automatic, so we should return false to avoid doing a manual broadcast

fixup commit changes this but will revert in a future commit, that will also include an e2e test

tnull · 2025-06-26T11:31:59Z

lightning-liquidity/src/lsps2/service.rs

+
+	fn new(client_trusts_lsp: bool) -> Self {
+		if client_trusts_lsp {
+			return TrustModel::ClientTrustsLsp {


nit: Please avoid these explicit returns here.

tnull · 2025-06-26T11:34:27Z

lightning-liquidity/src/lsps2/service.rs

+		if client_trusts_lsp {
+			return TrustModel::ClientTrustsLsp {
+				funding_tx_broadcast_safe: false,
+				htlc_claimed: false,


nit: Maybe payment_claimed to align with the event type?

tnull · 2025-06-26T11:41:25Z

lightning-liquidity/src/lsps2/service.rs

 				let mut payment_queue = core::mem::take(payment_queue);
 				payment_queue.add_htlc(htlc);
 				*self = OutboundJITChannelState::PendingChannelOpen {
 					payment_queue,
 					opening_fee_msat: *opening_fee_msat,
+					trust_model: trust_model.clone(),


Would be good if we could find a way to avoid these clones. Given that these are just two bools and the transaction option, I also wonder if it's indeed worth all the boilerplate, or if it might suffice to have these fields live on the state/channel objects directly.

tnull · 2025-06-26T11:52:44Z

lightning-liquidity/src/lsps2/service.rs

+		Ok(())
+	}
+
+	/// Called by ldk-node when the funding transaction is safe to broadcast.


Note that in this context we don't know where this will be used, so we shouldn't assume LDK Node is the only consumer of this API.

tnull · 2025-06-26T11:53:47Z

lightning/src/ln/channelmanager.rs

+	/// broadcast it manually.
+	///
+	/// Used in LSPS2 on a client_trusts_lsp model
+	CheckedManualBroadcast(Transaction),


nit: Let's move to the second positition here and elsewhere.

tnull · 2025-06-26T11:55:13Z

lightning/src/ln/channelmanager.rs

+	/// # Warning
+	/// Improper use of this method could lead to channel state inconsistencies.
+	/// Ensure the transaction being broadcast is valid and expected by LDK.
+	pub fn unsafe_broadcast_transaction(&self, tx: &Transaction) {


Hmm, I'm not sure if this would qualify for the unsafe_ prefix and the Warning. It's really just the normal flow, just that we leave broadcasting to the user instead of using the BroadcasterInterface.

we leave broadcasting to the user instead of using the BroadcasterInterface

actually, I think it would be good to emit an event ClientPaidSoPleaseBroadcastTransactionNow instead of doing it automatically, or even better, reuse the LdkEvent::FundingTxBroadcastSafe, which is literally the event used to let the user know they should manually broadcast a transaction. I will investigate if that's possible

tnull · 2025-06-26T11:55:24Z

lightning/src/routing/router.rs

@@ -1075,7 +1075,7 @@ impl PaymentParameters {
 }

 /// A struct for configuring parameters for routing the payment.
-#[derive(Clone, Copy)]
+#[derive(Clone, Copy, Debug)]


This seems unrelated?

tnull · 2025-06-26T11:55:50Z

lightning-transaction-sync/Cargo.toml

@@ -35,7 +35,7 @@ lightning = { version = "0.2.0", path = "../lightning", default-features = false
 lightning-macros = { version = "0.2", path = "../lightning-macros", default-features = false }
 bitcoin = { version = "0.32.2", default-features = false }
 futures = { version = "0.3", optional = true }
-esplora-client = { version = "0.12", default-features = false, optional = true }
+esplora-client = { version = "0.11", default-features = false, optional = true }


Please don't include unrelated changes here.

ldk-reviews-bot · 2025-06-26T12:01:29Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

tnull · 2025-07-24T09:03:07Z

This needs a rebase now that #3662 landed.

tnull

Please let me know if/when you deem this ready for review!

martinsaposnic · 2025-08-18T15:06:36Z

Please let me know if/when you deem this ready for review!

I'm close, I have a half baked functional test. I want to finish that before putting this as ready for review

martinsaposnic · 2025-08-18T20:45:03Z

ok, this should be ready now @tnull

all comments are addressed in fixup commits.

also I wrote a full end to end test that covers the client_trusts_lsp flow (directly in this repo, not in ldk-node, which was not possible before! 😄 ) . also added some documentation that explains how the client_trusts_lsp flow works.

thanks!

TheBlueMatt

Didn't review the integration tests.

TheBlueMatt · 2025-08-18T20:55:51Z

lightning/src/ln/channelmanager.rs

@@ -11546,6 +11568,15 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
 		}
 	}

+	/// Manually broadcast a transaction using the internal transaction broadcaster.


I don't really see the point of a method that just calls back into a user-provided interface? The caller in lightning-liquidity should probably just have a reference to the broadcaster.

TheBlueMatt · 2025-08-18T20:56:16Z

lightning/src/ln/channelmanager.rs

@@ -5767,6 +5775,18 @@ where
 		self.batch_funding_transaction_generated_intern(temporary_chans, funding_type)
 	}

+	/// Same as batch_funding_transaction_generated but it does not automatically broadcast the funding transaction


Isn't this the same as funding_transaction_generated? Also, this should be a link and at least link to Event::FundingTxBroadcastSafe

TheBlueMatt · 2025-08-18T21:01:14Z

lightning-liquidity/src/lsps2/service.rs

+	ClientTrustsLsp {
+		funding_tx_broadcast_safe: bool,
+		payment_claimed: bool,
+		funding_tx: Option<Arc<Transaction>>,


Don't see a reason this should be in an Arc.

TheBlueMatt · 2025-08-18T21:04:22Z

lightning-liquidity/src/lsps2/service.rs

@@ -414,6 +500,9 @@ impl OutboundJITChannel {

 	fn payment_forwarded(&mut self) -> Result<Option<ForwardHTLCsAction>, LightningError> {
 		let action = self.state.payment_forwarded()?;
+		if action.is_some() {
+			self.trust_model.set_payment_claimed(true);


I don't think we currently test whether the HTLC that caused us to open the channel was forwarded or just any channel. I imagine someone could get enough in pending HTLCs to get a channel, then route a single sat to themselves, claim that, and get the funding broadcasted (this should probably be explicitly tested).

what I will do here is track an outstanding_opening_fee_msat (this is the amount of fees that the client promised to pay), and as the PaymentForwards come, I will substract the skimmed fees from it, until it's <= 0

~~once it's <= 0, it means that it's now safe for the LSP to proceed and broadcast the funding tx.~~

I did it this way because the PaymentForward does not tell what htlc was forwarded (I guess that's intentional?), so I cannot tell what HTLC exactly the client is claiming. it just tells me the channel and the skimmed fees.

I have the code ready, I'm improving the tests to cover some edge cases.

@TheBlueMatt please let me know if this makes sense conceptually or if I'd need to do something else

d53c466

I actually went with a simple approach without a paid fees accumulator FYI

Please correct me if I’m missing something, but I don’t think this attack is actually possible.

someone could get enough in pending HTLCs to get a channel, then route a single sat to themselves, claim that, and get the funding broadcasted

If the client already has a PaymentClaimable that would cover the opening fee once claimed but instead routes a 1 sat payment to themselves through the service, the service will intercept that 1 sat HTLC and do nothing (won’t forward it) because the state machine is in PendingPaymentForward waiting for the earlier payment to resolve.

If the client fails the earlier HTLC instead of claiming it and then routes a 1 sat payment to themselves, the state machine will be in PendingPayment. When the service intercepts the 1 sat payment, it checks
whether the queued HTLCs meet opening_fee_msat. A single sat doesn’t, so nothing is forwarded.

The only real risk is if the caller feeds incorrect PaymentForwarded events to the payment_forwarded function, but I don't think we should worry about this right?

If the client already has a PaymentClaimable that would cover the opening fee once claimed but instead routes a 1 sat payment to themselves through the service, the service will intercept that 1 sat HTLC and do nothing (won’t forward it) because the state machine is in PendingPaymentForward waiting for the earlier payment to resolve.

Currently, because LDK doesn't support full HTLC interception, the client can bypass this with an HTLC using the chanel's SCID alias rather than the forwarding SCID.

TheBlueMatt · 2025-08-18T21:05:01Z

lightning-liquidity/src/lsps2/service.rs

+	}
+
+	/// Called when the funding transaction is safe to broadcast.
+	/// This marks the funding_tx_broadcast_safe flag as true for the given user_channel_id.


funding_tx_broadcast_safe this isnt a public thing so shouldnt appear in docs.

I will improve the name and docs of this function, but I'm still confused with what you mean by "funding_tx_broadcast_safe is not a public thing"

I'm making it necessary to call funding_tx_broadcast_safe() BEFORE being able to broadcast the funding tx. is this incorrect?

Sorry, I meant "the funding_tx_broadcast_safe flag", which isn't public, specifically.

the new method funding_transaction_generated_manual_broadcast is following the same guidance as unsafe_manual_funding_transaction_generated for the broadcast logic.

from the unsafe_manual_funding_transaction_generated docs:

https://github.com/lightningdevkit/rust-lightning/blob/main/lightning/src/ln/channelmanager.rs#L5748-L5750

/// Note that if this method is called successfully, the funding transaction won't be /// broadcasted and you are expected to broadcast it manually when receiving the /// [`Event::FundingTxBroadcastSafe`] event.

so I made it mandatory that the user needs to call the LSPS2/service when they receive the FundingTxBroadcastSafe event, as a pre-requisite for broadcasting the funding tx.

I would love to get rid of this, but I don't know if it's possible. I will explore if it is though

TheBlueMatt · 2025-08-18T21:05:36Z

lightning-liquidity/src/lsps2/service.rs

+		Ok(())
+	}
+
+	/// Called when the funding transaction is safe to broadcast.


This needs a discussion of what "safe to broadcast" means, cause its not actually "safe to broadcast" in the context of LSPS, only in the context of lightning. Should at least link to the lightning Event.

tnull · 2025-08-20T11:56:40Z

lightning-background-processor/src/lib.rs

@@ -631,7 +631,7 @@ use futures_util::{dummy_waker, Joiner, OptionalSelector, Selector, SelectorOutp
 /// # type P2PGossipSync<UL> = lightning::routing::gossip::P2PGossipSync<Arc<NetworkGraph>, Arc<UL>, Arc<Logger>>;
 /// # type ChannelManager<B, F, FE> = lightning::ln::channelmanager::SimpleArcChannelManager<ChainMonitor<B, F, FE>, B, FE, Logger>;
 /// # type OnionMessenger<B, F, FE> = lightning::onion_message::messenger::OnionMessenger<Arc<lightning::sign::KeysManager>, Arc<lightning::sign::KeysManager>, Arc<Logger>, Arc<ChannelManager<B, F, FE>>, Arc<lightning::onion_message::messenger::DefaultMessageRouter<Arc<NetworkGraph>, Arc<Logger>, Arc<lightning::sign::KeysManager>>>, Arc<ChannelManager<B, F, FE>>, lightning::ln::peer_handler::IgnoringMessageHandler, lightning::ln::peer_handler::IgnoringMessageHandler, lightning::ln::peer_handler::IgnoringMessageHandler>;
-/// # type LiquidityManager<B, F, FE> = lightning_liquidity::LiquidityManager<Arc<lightning::sign::KeysManager>, Arc<lightning::sign::KeysManager>, Arc<ChannelManager<B, F, FE>>, Arc<F>, Arc<DefaultTimeProvider>>;
+/// # type LiquidityManager<B, F, FE> = lightning_liquidity::LiquidityManager<Arc<lightning::sign::KeysManager>, Arc<lightning::sign::KeysManager>, Arc<ChannelManager<B, F, FE>>, Arc<F>, Arc<DefaultTimeProvider>, Arc<lightning::chain::chaininterface::BroadcasterInterface>>;


Seems this makes the doctests CI unhappy.

martinsaposnic · 2025-08-21T00:09:27Z

alright, comments are addressed in fixup commits and CI is passing.

let me know what you think, thanks! @TheBlueMatt @tnull

tnull

Took a ~high level pass. Have yet to fully review all the details (esp. in conjunction with the LDK Node counterpart), but here are some comments.

In particular, I think there is a misconception: LSP-trusts-client doesn't mean we don't verify the fees paid, it's only that we broadcast immediately instead of waiting for the client to claim sufficient parts to pay for the channel open.

tnull · 2025-08-21T11:16:15Z

lightning-liquidity/src/lsps2/service.rs

+					return Ok(None);
+				}
+
+				if skimmed_fee_msat.unwrap() >= *opening_fee_msat {


Never unwrap on something like this in production code. Please see the API of LSPS2ServiceHandler::payment_forwarded, where we decidedly didn't make next_channel_id an Option, as it requires that the user unwraps if they are certain that their LDK version supports it.

tnull · 2025-08-21T11:18:40Z

lightning-liquidity/src/lsps2/service.rs

-				let forward_htlcs = ForwardHTLCsAction(*channel_id, payment_queue.clear());
-				*self = OutboundJITChannelState::PaymentForwarded { channel_id: *channel_id };
-				Ok(Some(forward_htlcs))
+				if !client_trusts_lsp {


No, even for LSP-trusts-client we only want to forward once the client has paid for the channel open.

tnull · 2025-08-21T11:19:33Z

lightning-liquidity/src/lsps2/service.rs

+					return Ok(Some(forward_htlcs));
+				}
+
+				if skimmed_fee_msat.is_none() {


Why do we need this if here, if we're duplicating it below?

tnull · 2025-08-21T11:21:09Z

lightning-liquidity/src/lsps2/service.rs

-	/// `skimmed_fee_msat` in [`Event::PaymentForwarded`].
+	/// and future HTLCs for the SCID of the initial invoice.
+	///
+	/// If client_trusts_lsp=true, this method will verify the `skimmed_fee_msat` in [`Event::PaymentForwarded`].


No, as mentioned above, we should always verify the skimmed fee before forwarding.

tnull · 2025-08-21T11:24:11Z

lightning-liquidity/tests/lsps2_integration_tests.rs

@@ -2,38 +2,59 @@

 mod common;

-use common::{create_service_and_client_nodes, get_lsps_message, LSPSNodes, LiquidityNode};


I'm not quite sure how a sudden reordering of imports relates to this issue? If we want to change the import order we usually apply, let's make it a different PR, and a systematic crate-wide change.

TheBlueMatt · 2025-08-22T18:19:43Z

lightning-liquidity/src/lsps2/service.rs

+		Ok(())
+	}
+
+	/// This should be called when the event [`Event::FundingTxBroadcastSafe`] is received.


I believe we intended the lightning-liquidity to support non-LDK backends, which would imply that we should describe what this means (the "that channel has gotten signatures for the funding tx and the lightning state machine is ready to broadcast, though the ultimately broadcast has to be done by the LSPS service to ensure we have received payment first").

martinsaposnic · 2025-08-25T18:10:54Z

thanks for the comments!

just pushed 2 fixup commits addressing the latest comments:

the skimmed_fee validation now applies to both lsp_trusts_client and client_trusts_lsp, so on both flows we forward all payments after the client claims the payment and pays the fee, but only on client_trusts_lsp it triggers the broadcast_funding_tx

also improved set_funding_tx_broadcast_safe docs, but there is still an open question related to that #3838 (comment) @TheBlueMatt

ldk-reviews-bot · 2025-08-27T18:11:29Z

🔔 1st Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt

Basically LGTM if we just drop the new broadcast event. Feel free to squash, in any case.

TheBlueMatt · 2025-08-29T20:49:49Z

lightning-liquidity/src/lsps2/service.rs

-	pub fn payment_forwarded(&self, next_channel_id: ChannelId) -> Result<(), APIError> {
+	/// [`Event::BroadcastFundingTransaction`]: crate::lsps2::event::LSPS2ServiceEvent::BroadcastFundingTransaction
+	pub fn payment_forwarded(
+		&self, next_channel_id: ChannelId, skimmed_fee_msat: Option<u64>,


IMO skimmed_fee_msat shouldn't be an Option. That implies to a user that they can skip it. Its only an Option in the corresponding Event for serialization backwards compatibility, but we should push the user to simmed_fee_msat.unwrap_or(0).

TheBlueMatt · 2025-08-29T21:07:07Z

lightning-liquidity/src/lsps2/service.rs

+	///
+	/// This method should only be used when manual control over transaction
+	/// broadcast timing is required (e.g. client_trusts_lsp=true)
+	pub fn broadcast_transaction(&self, tx: &Transaction) {


I'm really not sure what the point of this is. We're already holding a reference to the BroadcasterInterface (now), so why are we creating an Event with the sole purpose of making the user call a method back on the code that generated the event? Why can't we just do the broadcast directly and remove the event entirely? And, if we keep the event, what's the point of having a BroadcasterInterface reference is its just used for a public method that proxies it.

push the user to simmed_fee_msat.unwrap_or(0)

martinsaposnic · 2025-09-01T12:00:53Z

thanks for the review @TheBlueMatt !

all fixups are squashed, and also addressed the latest comments in new fixup commits

thanks!!

…r broadcasts funding tx

TheBlueMatt

Fixups LGTM, I'll leave it to @tnull to look at this one last time and request remaining fixups be squashed.

tnull self-requested a review June 9, 2025 19:17

martinsaposnic mentioned this pull request Jun 9, 2025

Client trusts lsp lightningdevkit/ldk-node#572

Open

martinsaposnic force-pushed the client-trusts-lsp branch 2 times, most recently from 5d8508d to a038ab6 Compare June 9, 2025 19:51

tnull reviewed Jun 26, 2025

View reviewed changes

martinsaposnic force-pushed the client-trusts-lsp branch from a038ab6 to eb5f42f Compare July 23, 2025 12:31

martinsaposnic force-pushed the client-trusts-lsp branch 3 times, most recently from 8d7da60 to 82a4bc1 Compare August 12, 2025 18:11

tnull reviewed Aug 18, 2025

View reviewed changes

martinsaposnic force-pushed the client-trusts-lsp branch 3 times, most recently from fb259f4 to 6412945 Compare August 18, 2025 20:38

martinsaposnic marked this pull request as ready for review August 18, 2025 20:45

ldk-reviews-bot requested a review from jkczyz August 18, 2025 20:45

TheBlueMatt removed the request for review from jkczyz August 18, 2025 20:54

TheBlueMatt self-requested a review August 18, 2025 20:54

TheBlueMatt reviewed Aug 18, 2025

View reviewed changes

tnull self-requested a review August 19, 2025 10:51

martinsaposnic force-pushed the client-trusts-lsp branch from 7fd8c8c to 644cec2 Compare August 19, 2025 15:02

tnull reviewed Aug 20, 2025

View reviewed changes

martinsaposnic force-pushed the client-trusts-lsp branch 3 times, most recently from 208351c to 37066e4 Compare August 20, 2025 21:40

martinsaposnic requested review from tnull and TheBlueMatt August 21, 2025 00:09

tnull reviewed Aug 21, 2025

View reviewed changes

TheBlueMatt reviewed Aug 22, 2025

View reviewed changes

martinsaposnic force-pushed the client-trusts-lsp branch from 37066e4 to 7cfa0b4 Compare August 25, 2025 17:24

martinsaposnic requested a review from TheBlueMatt August 25, 2025 18:11

TheBlueMatt reviewed Aug 29, 2025

View reviewed changes

TheBlueMatt added this to the 0.2 milestone Aug 30, 2025

martinsaposnic added 2 commits September 1, 2025 08:36

Support client_trusts_lsp on LSPS2

3abc7f1

fixup: make skimmed_fee_msat not optional.

e8e794f

push the user to simmed_fee_msat.unwrap_or(0)

martinsaposnic force-pushed the client-trusts-lsp branch from 7cfa0b4 to eb77ece Compare September 1, 2025 12:00

fixup: just broadcast funding tx instead of emitting event so the use…

90ea0f8

…r broadcasts funding tx

martinsaposnic force-pushed the client-trusts-lsp branch from eb77ece to 90ea0f8 Compare September 1, 2025 12:03

martinsaposnic requested review from tnull and TheBlueMatt September 1, 2025 12:49

TheBlueMatt reviewed Sep 1, 2025

View reviewed changes

		@@ -2,38 +2,59 @@

		mod common;

		use common::{create_service_and_client_nodes, get_lsps_message, LSPSNodes, LiquidityNode};

Support client_trusts_lsp on LSPS2 #3838

Are you sure you want to change the base?

Support client_trusts_lsp on LSPS2 #3838

Conversation

martinsaposnic commented Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The feature

The plan:

Changes:

LDK Node integration

Uh oh!

ldk-reviews-bot commented Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

martinsaposnic commented Jun 9, 2025

Uh oh!

ldk-reviews-bot commented Jun 11, 2025

Uh oh!

ldk-reviews-bot commented Jun 14, 2025

Uh oh!

ldk-reviews-bot commented Jun 16, 2025

Uh oh!

ldk-reviews-bot commented Jun 18, 2025

Uh oh!

ldk-reviews-bot commented Jun 21, 2025

Uh oh!

ldk-reviews-bot commented Jun 23, 2025

Uh oh!

ldk-reviews-bot commented Jun 25, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

martinsaposnic Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Jun 26, 2025

Uh oh!

tnull commented Jul 24, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

martinsaposnic commented Aug 18, 2025

Uh oh!

martinsaposnic commented Aug 18, 2025

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

martinsaposnic commented Jun 9, 2025 •

edited

Loading

ldk-reviews-bot commented Jun 9, 2025 •

edited

Loading

codecov bot commented Jun 9, 2025 •

edited

Loading

martinsaposnic Jul 23, 2025 •

edited

Loading

martinsaposnic Aug 19, 2025 •

edited

Loading