Skip to content
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

Add general-purpose HTLC interception interface #2855

Open
tnull opened this issue Jan 26, 2024 · 3 comments
Open

Add general-purpose HTLC interception interface #2855

tnull opened this issue Jan 26, 2024 · 3 comments
Assignees

Comments

@tnull
Copy link
Contributor

tnull commented Jan 26, 2024

While we currently allow to intercept HTLCs based on magic-value SCIDs, LDK is currently lacking the capability to intercept HTLCs and give users control over claiming/forwarding/failing them.

As this feature has been regularly requested, we should add (optional) support for this, which would also give users the freedom to implement more advanced HTLC forwarding algorithms on top.

Related issues that might be closed/superseded by this:
#2320
#2425
#2839

@tnull
Copy link
Contributor Author

tnull commented Jan 26, 2024

Tagging myself as I might be interested in working on this, even if not immediately.

@MaxFangX
Copy link
Contributor

FYI we've worked around this somewhat by simply always including the magic-value SCID for user-generated invoices.

More important for us is an interface where we can just claim funds using a preimage received out-of-band (as elaborated on in #2839), in order to implement something akin to Phoenix's fee credits.

@tnull
Copy link
Contributor Author

tnull commented Nov 15, 2024

More important for us is an interface where we can just claim funds using a preimage received out-of-band (as elaborated on in #2839), in order to implement something akin to Phoenix's fee credits.

Do you mind opening a separate issue for this, describing your particular requirements for such an interface?

FWIW, we might need parts of it for integration of Liquidity Ads-based just-in-time channels (i.e., the parts that would allow forwarding the to-be-forwarded onions ahead of time to allow client-side validation before sending a 'would claim' message, all before a channel is opened). So might be good to learn what your needs are to make sure we create an API that's reusable for both usecases.

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

2 participants