HtlcInterceptor - How To Safely "Fail Back" HTLCs Already Sent Through Unconfirmed Zero-Conf Channel.

[MegalithicBTC]

I have a question which I have run into while usingHtlcInterceptor... https://lightning.engineering/api-docs/api/lnd/router/htlc-interceptor/

I'm implementing the LSPS2/blip52 spec .. https://github.com/lightning/blips/blob/a833e7b49f224e1240b5d669e78fa950160f5a06/blip-0052.md ..

... I'm opening zero-conf channels using the PBST flow, like

  fundingShim: {
      psbtShim:

so these are UNSIGNED funding transactions, which I use in OpenChannel but, following the LSPS2/Blip52 spec, I do NOT publish the transaction immediately.

.. and then I am using the HTLC interceptor to do various complicated things with the HTLCs

.. and then ultimately I am forwarding these HTLCs over the zero-conf channel to the client peer BEFORE I publish the funding TX.

✅ All of this works well and I've been able to implement the full LSPS2 spec and test it with a couple different clients.

... but an edge case is: HTLCs which I forward over the zero-conf channel that DO NOT SETTLE. (This could happen because of a malicious or misbehaving client peer).

If the receiver of the channel (the "client peer") DOES NOT SETTLE the HTLCs, ultimately I need to cancel the whole operation and NOT publish the funding TX.

Concretely: the funding TX was never broadcast. I forwarded the HTLC to the client peer over an unconfirmed channel. Now I want to abort: fail the HTLC back to the sender and remove the channel from LND's state.

This is tricky, because I have already forwarded the HTLCs. Doing things like CloseChannel or AbandonChannel AFTER these HTLCs have been forwarded through the channel is obviously bad. I really need to CANCEL and FAIL BACK these HTLCs BEFORE I close or abandon the channel.

But at the same time, once I've made the forwards, I don't think LND has a way to fail them back, right?

Or does LND actually have a path to achieve this?

Thanks!

[MegalithicBTC]

Discussion with z-man. Seems like the Lightning protocol could support this. But I'm not sure if it's something that LND supports or would even be interested in supporting, given the danger of misuse?

[ziggie1984]

Hey thank you for reaching out,

so I understand your usecase and agree that Force-Closing the channel is not really the right way to do it. I would rather say a combination of canceling back the incoming HTLC with the combination of Abandoning the channel would be an acceptable way.

I am not quite sure what z-man means when talking about the hook. Does he mean that you want to execute a function before force-closing a channel (like for example not doing anything when force-closing the channel but triggering the resolving of the incoming HTLC)? In general I would not start allow canceling an HTLC on a channel although it is still on the commitment transaction so in your case I would probably recommend canceling the incoming HTLC but we still would keep the HTLC on the outgoing channel which you would need to abandon to get rid of it.

In general we would need to introduce something like this, and it might also make sense to do so, because imagine in high fee scenarios where you know the outgoing HTLC is not resolving due to not being economical. However it obviously comes with a risk and we need to decide whether we allow such things because people might start misusing it. We talk to the team to decide whether we are going to create and issue and implement such a API in the future.

[cdecker]

I wonder if this could not just wait for things to time out. The incoming channel has an HTLC, that we forward to the downstream channel. The downstream channel is not published unless the downstream HTLC is claimed. So if we're ok with the timeout, and maybe having the funds inaccessible for the duration of that HTLC timeout, we could just let the normal machinery take care of things, couldn't we?

1. We get an incoming HTLC (a), with timeout T_a
2. We fund a channel, but don't broadcast the funding
3. We forward the HTLC (b), with timeout T_b < T_a
4. The peer never claims the HTLC
5. T_b hits, and our node automatically drops to chain for channel b, but importantly keeps channel a active because T_a > T_b
6. The HTLC b gets settled on-chain (refund, the peer never claims it)
7. The LSP node is still in time to cancel the upstream HTLC a, keeping the upstream channel clean and functioning (this is all native LN behaviour and part of the security parametrization ensuring cascades don't happen)

If at any point b gets settled, we can immediately replicate that to a, so let's wait for b to resolve, no shortcut.

This presumes that you are ok, keeping the funds allocated to the channel for the HTLC timeout duration (~1day). If you don't want that, you can also double-spend the funding that has not been broadcast, though that can lead to very inconsistent states if the peer ends up claiming after the double spend. Double-spending can prevent the channel from ever confirming, and allows concurrent reuse of liquidity, however you are actively going back on a promise ("I promise you the HTLC amount, if you give me the preimage") so better be sure this is what you want.