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.

Sign up for GitHub

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

Jump to bottom

Ensure UPDATE errors have an update #1879

Closed
TheBlueMatt opened this issue Nov 28, 2022 · 1 comment · Fixed by #1895
Closed

Ensure UPDATE errors have an update #1879

TheBlueMatt opened this issue Nov 28, 2022 · 1 comment · Fixed by #1895
Assignees
@TheBlueMatt
Milestone
0.0.113

Comments

@TheBlueMatt
Copy link
Collaborator

cc #1835 (comment)
@TheBlueMatt TheBlueMatt added this to the 0.0.113 milestone Nov 28, 2022
@TheBlueMatt TheBlueMatt mentioned this issue Nov 28, 2022
Merged
@TheBlueMatt
Copy link
Collaborator Author

WIth the constructors in #1880 we can assert this too.

@TheBlueMatt TheBlueMatt mentioned this issue Dec 1, 2022
Merged
@TheBlueMatt TheBlueMatt self-assigned this Dec 1, 2022
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Dec 1, 2022
@TheBlueMatt
Assert that all onion error messages are correct len in tests
7e29b27 
When we're constructing an HTLCFailReason, we should check that we
set the data to at least the correct length for the given failure
code, which we do here.

Fixes lightningdevkit#1879
@TheBlueMatt TheBlueMatt mentioned this issue Dec 1, 2022
Merged
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Dec 1, 2022
@TheBlueMatt
Assert that all onion error messages are correct len in tests
db345a5 
When we're constructing an HTLCFailReason, we should check that we
set the data to at least the correct length for the given failure
code, which we do here.

Fixes lightningdevkit#1879
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Dec 1, 2022
@TheBlueMatt
Use temporary_node_failure for a phantom HTLC with bogus CLTV
c45669a 
When we receive a phantom HTLC with a bogus/modified CLTV, we
should fail back with `incorrect_cltv_expiry`, but that requires a
`channel_update`, which we cannot generate for a phantom HTLC which
has no corresponding channel. Thus, instead, we have to fall back
to `incorrect_cltv_expiry`.

Fixes lightningdevkit#1879
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Dec 2, 2022
@TheBlueMatt
Use temporary_node_failure for a phantom HTLC with bogus CLTV
ebf7f6e 
When we receive a phantom HTLC with a bogus/modified CLTV, we
should fail back with `incorrect_cltv_expiry`, but that requires a
`channel_update`, which we cannot generate for a phantom HTLC which
has no corresponding channel. Thus, instead, we have to fall back
to `incorrect_cltv_expiry`.

Fixes lightningdevkit#1879
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Dec 2, 2022
@TheBlueMatt
Use temporary_node_failure for a phantom HTLC with bogus CLTV
80b1f21 
When we receive a phantom HTLC with a bogus/modified CLTV, we
should fail back with `incorrect_cltv_expiry`, but that requires a
`channel_update`, which we cannot generate for a phantom HTLC which
has no corresponding channel. Thus, instead, we have to fall back
to `incorrect_cltv_expiry`.

Fixes lightningdevkit#1879
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Dec 5, 2022
@TheBlueMatt
Use temporary_node_failure for a phantom HTLC with bogus CLTV
aa22407 
When we receive a phantom HTLC with a bogus/modified CLTV, we
should fail back with `incorrect_cltv_expiry`, but that requires a
`channel_update`, which we cannot generate for a phantom HTLC which
has no corresponding channel. Thus, instead, we have to fall back
to `incorrect_cltv_expiry`.

Fixes lightningdevkit#1879
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Dec 6, 2022
@TheBlueMatt
Use temporary_node_failure for a phantom HTLC with bogus CLTV
eb70e92 
When we receive a phantom HTLC with a bogus/modified CLTV, we
should fail back with `incorrect_cltv_expiry`, but that requires a
`channel_update`, which we cannot generate for a phantom HTLC which
has no corresponding channel. Thus, instead, we have to fall back
to `incorrect_cltv_expiry`.

Fixes lightningdevkit#1879
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Dec 6, 2022
@TheBlueMatt
Use temporary_node_failure for a phantom HTLC with bogus CLTV
6daf62f 
When we receive a phantom HTLC with a bogus/modified CLTV, we
should fail back with `incorrect_cltv_expiry`, but that requires a
`channel_update`, which we cannot generate for a phantom HTLC which
has no corresponding channel. Thus, instead, we have to fall back
to `incorrect_cltv_expiry`.

Fixes lightningdevkit#1879
@TheBlueMatt TheBlueMatt mentioned this issue Dec 7, 2022
Merged
optout21 pushed a commit to optout21/rust-lightning that referenced this issue Jul 24, 2023
@TheBlueMatt @optout21
Use temporary_node_failure for a phantom HTLC with bogus CLTV
7aefde3 
When we receive a phantom HTLC with a bogus/modified CLTV, we
should fail back with `incorrect_cltv_expiry`, but that requires a
`channel_update`, which we cannot generate for a phantom HTLC which
has no corresponding channel. Thus, instead, we have to fall back
to `incorrect_cltv_expiry`.

Fixes lightningdevkit#1879
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@TheBlueMatt TheBlueMatt

Labels
None yet
Projects
None yet
Milestone
0.0.113
Development

Successfully merging a pull request may close this issue.

Fix some onion errors and assert their length is correct TheBlueMatt/rust-lightning
1 participant
@TheBlueMatt