Uh oh!
There was an error while loading. Please reload this page.
(1/3) Minor error code fixes - #3699
Conversation
This failure code isn't used anywhere in the codebase and is not defined in BOLT 04.
I've assigned @valentinewallace as a reviewer! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@## main #3699 +/- ##
==========================================
- Coverage 89.17% 89.15% -0.02%
==========================================
Files 155 155 Lines 121023 121023 Branches 121023 121023 ==========================================
- Hits 107926 107904 -22 - Misses 10447 10461 +14 - Partials 2650 2658 +8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Uh oh!
There was an error while loading. Please reload this page.
vincenzopalazzo
left a comment
There was a problem hiding this comment.
Great clean up :) I left a comment, otherwise LGTM
carlaKC
commented
Apr 3, 2025
Pushed fixup for incorrect code for |
valentinewallace
left a comment
There was a problem hiding this comment.
Feel free to squash!
| if hop_data.intro_node_blinding_point.is_some() { | ||
| return Err(OnionDecodeErr::Relay { | ||
| err_msg: "Non-final intro node Trampoline onion data provided to us as last hop", | ||
| err_code: INVALID_ONION_BLINDING, |
Realm is no longer specified in BOLT04, use the specified version error instead.
As is, we're returning an `invalid_onion_blinding` error with no associated data, because the calling code does not attach any data when we have a `OnionDecodeErr::Relay` error. This is arguably not the correct error code anyway, as described below, so this commit updates it to `invalid_onion_payload` which does not require additional error data. In this case, we have received a trampoline payload which we believe should contain details of the next trampoline hop. This information is missing, so we've received an invalid payload. When a blinding point point is present in the payload, we're also the introduction node. BOLT04 indicates that if this `current_path_key` is present and we are the final hop we should return a regular error (rather than using `invalid_onion_blinding` when you're the the final hop). Before this commit, this code was considering our node to be non-final and returning an error accordingly. Our role as the final hop is ambiguous here - we are the final hop in the sphinx packet, but the trampoline packet implies that there should be more hops to come. Given that the trampoline packet is invalid, we defer to our position in the sphinx packet and send back an invalid payload error instead.
Although the specification allows an all-zero sha256_of_onion for invalid_onion_blinding errors, it still requires that the value is set.
This PR pulls a few trivial commits out of #3601 which deal with error code handling unrelated to the larger refactor.
Opening this up in a separate PR because it makes a change to one of the trampoline error codes that is a little spec-ambiguous, originally pointed out here.