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

Allow htlc_accepted hook to respond with UPDATE failure messages. #3705

Closed
tnull opened this issue May 5, 2020 · 2 comments
Closed

Allow htlc_accepted hook to respond with UPDATE failure messages. #3705

tnull opened this issue May 5, 2020 · 2 comments
Assignees

Comments

@tnull
Copy link

tnull commented May 5, 2020

Issue and Steps to Reproduce

I'm currently experimenting with a scenario in which I want to dynamically react to incoming HTLCs and, for example, adapt my channel policies. For this, I utilize the htlc_accepted hook offered by the plugin API and depending on the circumstances return a corresponding failure_message.

However, this currently does only work for failure messages that do not need additional parameters or require to append a channel update. That is, returning any failure message with the UPDATE/0x1000 failure code (cf. BOLT 04) currently results in an invalid fail onion.

It would be great if the plugin API would offer the ability to specify the additional fields required by the failure message or at least populate them with sane default values so failures with the UPDATE failure code could be returned by the htlc_accepted hook.

For my testing purposes, I implemented the latter approach, which can be seen here.

@cdecker cdecker self-assigned this Jul 18, 2020
@cdecker
Copy link
Member

cdecker commented Jul 18, 2020

Excellent idea, I'll see if I can add the full error payload as an argument.

@cdecker
Copy link
Member

cdecker commented Sep 28, 2020

This was addressed in #3472

@cdecker cdecker closed this as completed Sep 28, 2020
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