Refactor Sphinx failures #2955
Merged
Refactor Sphinx failures #2955
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
t-bast
force-pushed
the
refactor-sphinx-failure
branch
from
3b7b421 to
0330fff
Compare
|
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #2955 +/- ##
==========================================
- Coverage 86.19% 86.13% -0.06%
==========================================
Files 224 225 +1
Lines 20074 20136 +62
Branches 813 812 -1
==========================================
+ Hits 17302 17345 +43
- Misses 2772 2791 +19
|
t-bast
force-pushed
the
refactor-sphinx-failure
branch
3 times, most recently
from
bc3d507 to
8011fa3
Compare
When we fail to decrypt an onion failure packet, we should return the result of the unwrapping process. When using trampoline, this will let us properly re-encrypt the failure and relay it upstream to the previous trampoline node, until it reaches the sender.
We refactor the shared secret extraction to a dedicated function.
t-bast
force-pushed
the
refactor-sphinx-failure
branch
from
8011fa3 to
95931a4
Compare
We previously used an `Either[ByteVector, FailureMessage]` to encode: - a downstream error that we couldn't decrypt and must re-wrap (left) - a local error that we must encrypt (right) This won't be sufficient for trampoline, because we will need to handle the following cases: - a downstream error that we couldn't decrypt and must re-wrap - a local error for the node who created the *outer* onion (which we encrypt with the sphinx shared secret of the outer onion) - a local error for the node who created the *trampoline* onion (which we encrypt with the sphinx shared secret of the trampoline onion and then with the shared secret of the outer onion) We thus introduce a trait, which currently only contains the first two cases. We will extend this trait when adding support for trampoline failures. This is a pure refactoring without any behavior changes so far, which will simplify the future trampoline changes.
When we receive a (non-blinded) payment that uses trampoline, we keep the trampoline onion to be able to distinguish this payment from a non-trampoline payment.
t-bast
force-pushed
the
refactor-sphinx-failure
branch
from
95931a4 to
1376f0b
Compare
thomash-acinq
approved these changes
Dec 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains multiple independent commits, that should be reviewed separately. This is purely refactoring without any behavioral changes: the goal is to simplify the changes needed to implement the final spec version of trampoline (see #2819).
The main change is the third commit, in which we change
CMD_FAIL_HTLCfrom anEither[ByteVector, FailureMessage]to a sealed trait. See the commit message for more details.