You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #420 we added initial support for acting as an bLIP-52/LSPS2 service.
Currently, we simply hope the client will claim the HTLC after we opened this channel. To avoid potentially having the LSP being the target of griefing attacks, we should implement the full 'client-trusts-LSP' flow, i.e., only broadcast the funding transaction once the client claimed the payment.
Please tell me if I am wrong, but my understanding is that the only safe way to run LSPS2 (from the LSP side), would be in this "client-trusts-LSP" flow. My research on this led me to believe that, to guard against probing, as well as actual malicious attacks, the LSP must delay publishing the opening transaction until the payment is settled. I had some comments on this here: lightningnetwork/lnd#8882 (comment)
So I think that implementing an LSP for LDK clients (at least on our end) might need to wait on the "client-trusts-LSP" flow. If I'm wrong, please advise.
My research on this led me to believe that, to guard against probing, as well as actual malicious attacks, the LSP must delay publishing the opening transaction until the payment is settled.
Yes, it is true that to properly guard against this kind of behavior, you'll have to defer publishing the funding transaction, which is exactly what this issue is about.
So I think that implementing an LSP for LDK clients (at least on our end) might need to wait on the "client-trusts-LSP" flow. If I'm wrong, please advise.
That's fair and not wrong, though note that different LSPs might have different risk tolerances and different scenarios in mind. Some might be fine with not doing that for the time being, as long as they don't see no actual attacks happen etc.
Great, thanks for the clarification. On our end, the main reason we need to test closely with an LDK client is because we're going to need to implement custom behavior in LND for "delay publishing the opening transaction until the payment is settled"... and since this is nonstandard in LND... we need to REALLY be sure this works perfectly and test it under various conditions... so it seems prudent to hold off on starting this testing with LDK until this issue is closed....
Activity
MegalithicBTC commentedon Apr 17, 2025
Please tell me if I am wrong, but my understanding is that the only safe way to run LSPS2 (from the LSP side), would be in this "client-trusts-LSP" flow. My research on this led me to believe that, to guard against probing, as well as actual malicious attacks, the LSP must delay publishing the opening transaction until the payment is settled. I had some comments on this here: lightningnetwork/lnd#8882 (comment)
So I think that implementing an LSP for LDK clients (at least on our end) might need to wait on the "client-trusts-LSP" flow. If I'm wrong, please advise.
tnull commentedon Apr 18, 2025
Yes, it is true that to properly guard against this kind of behavior, you'll have to defer publishing the funding transaction, which is exactly what this issue is about.
That's fair and not wrong, though note that different LSPs might have different risk tolerances and different scenarios in mind. Some might be fine with not doing that for the time being, as long as they don't see no actual attacks happen etc.
MegalithicBTC commentedon Apr 18, 2025
Great, thanks for the clarification. On our end, the main reason we need to test closely with an LDK client is because we're going to need to implement custom behavior in LND for "delay publishing the opening transaction until the payment is settled"... and since this is nonstandard in LND... we need to REALLY be sure this works perfectly and test it under various conditions... so it seems prudent to hold off on starting this testing with LDK until this issue is closed....
tnull commentedon Jan 21, 2026
This was done in #687.