Skip to content

Return a malformed HTLC message when ephemeral pubkey is garbage #132

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

Merged

Conversation

TheBlueMatt
Copy link
Collaborator

This resolves a spec-compliance bug with BOLT 4 where we simply
failed to deserialize the message and thus could never return an
HTLC failure message. However, note that BOLT 4 incorrectly hints
that a non-malformed message should be used ("...MUST report a
route failure to the origin node") which we cannot do as we cannot
derive a SharedSecret to encrypt a regular update_fail_htlc message

@TheBlueMatt
Copy link
Collaborator Author

Moves #129 forward.

@TheBlueMatt TheBlueMatt force-pushed the 2018-08-bolt-4-spec-return-fail branch 2 times, most recently from 43d9164 to f26d0f3 Compare August 27, 2018 15:08
This resolves a spec-compliance bug with BOLT 4 where we simply
failed to deserialize the message and thus could never return an
HTLC failure message. However, note that BOLT 4 incorrectly hints
that a non-malformed message should be used ("...MUST report a
route failure to the origin node") which we cannot do as we cannot
derive a SharedSecret to encrypt a regular update_fail_htlc message
@TheBlueMatt TheBlueMatt force-pushed the 2018-08-bolt-4-spec-return-fail branch from f26d0f3 to a34e80f Compare August 27, 2018 15:47
@TheBlueMatt TheBlueMatt merged commit 7659877 into lightningdevkit:master Aug 27, 2018
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

Successfully merging this pull request may close these issues.

1 participant