Allow calling `claim_funds()` on intercepted HTLCs

[tvolk131]

Currently, according to documentation for HTLCIntercepted, ChannelManager::forward_intercepted_htlc or ChannelManager::fail_intercepted_htlc must be called in response to all intercepted HTLCs. Essentially we can either re-route the payment to a real channel, or unwind it. But what if we want to get the pre-image out-of-band? I'd like to be able to respond to an HTLCIntercepted event by fetching the pre-image outside of the lightning protocol and simply providing it to the ChannelManager to claim the funds. claim_funds() is just the method I'm looking for! If calling claim_funds() on intercepted HTLCs would already work, let's update the documentation to reflect this. If not, let's add support for it. Either way, we should update do_test_intercepted_payment().

For context, I'm working on building a Fedimint lightning gateway, where pre-images are received through what is essentially a federation-enforced HTLC, and the final hop happens separate from lightning.

[m1sterc001guy]

After some investigation, it looks like PaymentClaimable event should work for our use case.

Related discussion: fedimint/fedimint#3131

[tvolk131]

I have some time this weekend to hack away at a proof of concept using PaymentClaimable. Will share my results here!

[benthecarman]

After some investigation, it looks like PaymentClaimable event should work for our use case.

Was hacking with @tvolk131 today and realized that PaymentClaimable would not work for fedimints usecase. PaymentClaimable is only generated when you are the final hop in the route so this would mean the invoice would need to be generated by the gateway. Currently fedimint requires the client to generate the invoice and the gateway intercept the HTLC, so PaymentClaimable would never be generated.

It seems the only way to do this is using the HTLC interceptor, one question is that if you can use claim_funds for intercepted HTLCs. The docs do not indicate that you can but it seems the only way you'd claim an HTLC funds

[tnull]

Discussed this elsewhere in greater detail, but I think it would be a much simpler scheme to have the gateway generate the invoice and just be a simple Lightning node receiving a payment rather than dealing with (the limitations of) HTLC interception.

This could look like this, roughly:

                       ┌──────┐                      ┌───────┐
                       │Client│                      │Gateway│
                       └──┬───┘                      └───┬───┘
            Generate PH   │                              │
                          │                              │
                          │ Request invoice for PH       │
                          │ ───────────────────────────► │
                          │                              │  Register PH via ChannelManager::create_inbound_payment_for_hash
                          │     Invoice                  │
                          │ ◄─────────────────────────── │
                          │                              │
   Send invoice to payer  │                              │
◄─────────────────────────┤        ...                   │
                          │                              │ Inbound payment, Event::PaymentClaimable
                          │                              │ ◄───────────────────────────────────
                          │   Buy pre-image              │
                          │ ◄────────────────────────────┤
                          │                              │
                          │   Pre-image                  │
                          │ ──────────────────────────►  │
                          │                              │  Claim payment
                          │                              │

[TheBlueMatt]

This is definitely something we'd consider (it wouldn't be that hard to add), but (like with general intercept-all-HTLC's support) we'd really like to see a concrete design that needs it before moving forward there. As @tnull points out, for your usecase the gateway can simply generate the invoice (or, in a BOLT12 world, provide the blinded path to the client if you want them to generate the offer, or simply generate the offer itself). If there's some reason that's suboptimal, let us know and we can revisit this.

[tnull]

Closing this issue as superseded by #2855.