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

lnwire: encode channel_update type in onion errors #7665

Merged

Conversation

morehouse
Copy link
Collaborator

For about a year, the spec has prescribed encoding channel_updates with their type prefix (0x0102) in onion failure messages. LND can decode correctly with or without the prefix but hasn't been writing the prefix during encoding. This PR starts writing the prefix.

I ran across this while running some new encoding/decoding fuzz tests for onion errors, which I intend to submit in a separate PR. Those fuzz tests offer additional regression testing for this change.

Resolves #6461.

For about a year [1], the spec has prescribed encoding channel_updates
with their type prefix (0x0102) in onion failure messages. LND can
decode correctly with or without the prefix but hasn't been writing the
prefix during encoding. This commit starts writing the prefix.

[1] lightning/bolts#979
Copy link
Member

@yyforyongyu yyforyongyu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! I think we save the error message on disk, but when decoding it, because we use parseChannelUpdateCompatabilityMode, so we can always decode the newer format right?

@yyforyongyu yyforyongyu requested a review from guggero September 8, 2023 07:43
@morehouse
Copy link
Collaborator Author

I think we save the error message on disk, but when decoding it, because we use parseChannelUpdateCompatabilityMode, so we can always decode the newer format right?

Yes. Onion errors are deserialized from the DB in deserializeHTLCFailInfo, which calls lnwire.DecodeFailureMessage which calls the Decode method for that FailureMessage. All those Decode methods use parseChannelUpdateCompatibilityMode for decoding channel updates

Copy link
Member

@yyforyongyu yyforyongyu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM🙏

@yyforyongyu yyforyongyu added testing Improvements/modifications to the test suite fuzzing BOLTs labels Sep 10, 2023
@lightninglabs-deploy
Copy link

@guggero: review reminder

Copy link
Collaborator

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🎉

Going to change the base to 0-18-staging so we can get it merged.

@guggero guggero changed the base branch from master to 0-18-staging September 19, 2023 11:46
@guggero guggero merged commit 6c2417c into lightningnetwork:0-18-staging Sep 19, 2023
@morehouse morehouse deleted the onion_prefix_channel_update branch September 19, 2023 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BOLTs fuzzing no-changelog testing Improvements/modifications to the test suite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

lnwire: start to write the type byte when encoding channel updates in failures
4 participants