-
Notifications
You must be signed in to change notification settings - Fork 411
Decrypt Trampoline error onions #3657
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
Decrypt Trampoline error onions #3657
Conversation
👋 Thanks for assigning @joostjager as a reviewer! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Draft for now due to the clones, but am open to suggestions.
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
dd8098b
to
af31dd1
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3657 +/- ##
==========================================
+ Coverage 89.24% 89.25% +0.01%
==========================================
Files 155 155
Lines 119280 119584 +304
Branches 119280 119584 +304
==========================================
+ Hits 106446 106735 +289
- Misses 10240 10247 +7
- Partials 2594 2602 +8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
9caa2b6
to
a2dc11f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall clean approach where indeed failure message processing isn't touched all that much. Perhaps add some more comments explaining the code, especially for devs who do not fully understand trampoline, and isolate a bit more refactor into separate commits.
One question that I haven't fully answered is how this intersects with attributable failures. That pertains mainly to the spec level of course.
It might be nice to link to a tracking issue that links all trampoline work together? |
a2dc11f
to
e7d5c53
Compare
3e45cb2
to
36f8514
Compare
36f8514
to
83e58e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No major points. Still really happy with the commit structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Don't have any feedback on the first pass. Commit history is indeed very reviewable. Will take another look and more closely at the tests tomorrow.
In an upcoming commit, we will need to decrypt error onions constructed from multiple session_privs. In order to simplify the code legibility, we move from a single-iteration model to one where we first aggregate the shared secrets, and then use them for the error decryption.
We currently check whether our hop is the last in the path by accessing the hops vector by the next index. However, once we start handling Trampoline hops that will become inadequate. Instead, we switch it to check whether there is a subsequent element in the iterator.
When we start handling Trampoline, the hops in our error decryption path could be either `RouteHop`s or `TrampolineHop`s. To avoid excessive code duplication, we introduce an enum with some methods for common accessors.
83e58e9
to
98f2d38
Compare
59993a8
to
0f5cbdd
Compare
} => (path, session_priv, first_hop_htlc_msat), | ||
_ => { | ||
unreachable!() | ||
let (path, first_hop_htlc_msat) = match htlc_source { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you want to lift this out too, or is that a step too far?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if we want to do that quite yet given that I expect to have another HTLCSource variant we'll need to create and support here for the forwarding scenario
mut encrypted_packet: OnionErrorPacket, | ||
pub(super) fn process_onion_failure_inner<T: secp256k1::Signing, L: Deref>( | ||
secp_ctx: &Secp256k1<T>, logger: &L, htlc_source: &HTLCSource, outer_session_priv: &SecretKey, | ||
inner_session_priv: Option<&SecretKey>, mut encrypted_packet: OnionErrorPacket, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, love the explicitness of inner and outer
0f5cbdd
to
f03cc62
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, can always fix this nit in follow-up!
Rather than solely iterating over `RouteHop`s, we now also append the shared secrets from the inner onion containing `TrampolineHop`s. Additionally, we allow the `outer_session_priv` to be overridden to accommodate the test vector requirements. We do so by separating out a façade method without the override.
6d63c24
f03cc62
to
6d63c24
Compare
Small diff since @joostjager's ACK so this can land when CI is happy! |
No description provided.