Skip to content

Allow calling claim_funds() on intercepted HTLCs #2839

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tvolk131 opened this issue Jan 19, 2024 · 6 comments
Closed

Allow calling claim_funds() on intercepted HTLCs #2839

tvolk131 opened this issue Jan 19, 2024 · 6 comments

Comments

@tvolk131
Copy link

tvolk131 commented Jan 19, 2024

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
Copy link

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

Related discussion: fedimint/fedimint#3131

@tvolk131
Copy link
Author

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

@benthecarman
Copy link
Contributor

benthecarman commented Jan 20, 2024

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
Copy link
Contributor

tnull commented Jan 22, 2024

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
Copy link
Collaborator

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
Copy link
Contributor

tnull commented Jan 26, 2024

Closing this issue as superseded by #2855.

@tnull tnull closed this as completed Jan 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants