-
Notifications
You must be signed in to change notification settings - Fork 380
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
Route blinding groundwork #2128
Route blinding groundwork #2128
Conversation
Do have the followup commits somewhere? I'm a bit confused by the last two here on their own - we end up just renaming some structs so that we have two identical structs for onions, would be nice to see something that makes sense on its own. |
Here's the WIP commit that I'm slowly translating into PRs: valentinewallace@3460250#diff-350147204a45ffef3f58ea74ece349fe18296fbbf5a1e0a55acde6547f785a3dR1147 Link goes to the completed new It's fairly messy, so I'm also happy to close this PR until the follow-up(s) are open if that makes more sense. |
Yea, I guess I'd prefer to review something that's logically complete, or is at least split into two PRs that are ready to go. |
In upcoming blinded paths work, this method will grow to handle blinded forwards.
059bfe4
to
eb3af58
Compare
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## main #2128 +/- ##
==========================================
+ Coverage 90.23% 91.59% +1.36%
==========================================
Files 106 106
Lines 55213 70622 +15409
Branches 55213 70622 +15409
==========================================
+ Hits 49819 64688 +14869
- Misses 5394 5934 +540
☔ View full report in Codecov by Sentry. |
eb3af58
to
e9de303
Compare
53202ea
to
e76025a
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, one question.
lightning/src/ln/channelmanager.rs
Outdated
let (payment_data, keysend_preimage, payment_metadata) = match hop_data.format { | ||
msgs::OnionHopDataFormat::FinalNode { payment_data, keysend_preimage, payment_metadata } => | ||
(payment_data, keysend_preimage, payment_metadata), | ||
_ => | ||
return Err(InboundOnionErr { | ||
err_code: 0x4000|22, | ||
err_data: Vec::new(), | ||
msg: "Got non final data with an HMAC of 0", | ||
}), |
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.
Does it matter that this check happens before other checks now?
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 don't think so because these errors won't be processed until process_pending_htlc_forwards
is eventually called, so I don't think it changes any sort of timing from our peer's perspective.
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.
What I meant was, could we return a different error now if the order of the error checks have changed? Or does something preclude that? (i.e., the conditions leading to them do not overlap)
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.
Yeah, we might return a different error now if multiple errors apply. I don't think it matters, though. The one error that's in a different order now is the Got non final data with HMAC of 0
, which should be really rare/indicate a very buggy sender.
e76025a
to
0fa51de
Compare
0fa51de
to
b0b549c
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 assuming the fuzz discussions are resolved. Feel free to squash.
This also set us up for supporting receiving blinded onion payloads.
To support route blinding, we want to split OnionHopData into two separate structs, one for inbound onions and one for outbound onions. This is because blinded payloads change the fields present in the onion hop data struct based on whether we're sending vs receiving (outbound onions include encrypted blobs, inbound onions can decrypt those blobs and contain the decrypted fields themselves). In upcoming commits, we'll add variants for blinded payloads to the new InboundPayload enum.
Follows on from the previous commit, see its message
b0b549c
to
c9d3544
Compare
Squashed. @TheBlueMatt let me know on the fuzzing stuff. |
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.
Don't have much to add, LGTM
@@ -341,7 +341,7 @@ impl HTLCSource { | |||
} | |||
} | |||
|
|||
struct ReceiveError { | |||
struct InboundOnionErr { |
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.
nit: the error contents themselves here are generic failure codes for any error during HTLC receipt, I'm not sure why we need to rename the struct to refer to the onion decode error.
payment_data: Option<FinalOnionHopData>, | ||
payment_metadata: Option<Vec<u8>>, | ||
keysend_preimage: Option<PaymentPreimage>, | ||
amt_msat: u64, | ||
outgoing_cltv_value: u32, |
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.
Since this is now about the receiving end, do we want to rename this and the amount to be more descriptive? Same on the outbound edge.
@@ -3077,9 +3077,9 @@ impl<Signer: WriteableEcdsaChannelSigner> Channel<Signer> { | |||
|
|||
let mut htlc_updates = Vec::new(); | |||
mem::swap(&mut htlc_updates, &mut self.context.holding_cell_htlc_updates); | |||
let mut update_add_htlcs = Vec::with_capacity(htlc_updates.len()); | |||
let mut update_fulfill_htlcs = Vec::with_capacity(htlc_updates.len()); | |||
let mut update_fail_htlcs = Vec::with_capacity(htlc_updates.len()); |
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.
Yippee!
…followups #2128 follow-ups
This lays some groundwork for supporting sending and receiving over blinded payment paths.
To support route blinding, we want to split
OnionHopData
into two separatestructs, one for inbound onions and one for outbound onions. This is because
blinded payloads change the fields present in the onion hop data struct based
on whether we're sending vs receiving (outbound onions include encrypted blobs,
inbound onions can decrypt those blobs and contain the decrypted fields
themselves).
In upcoming work, we'll add variants for blinded payloads to the new enums.
Also includes a few small related refactors and code moves.