Lint 7298 #30
Closed
Lint 7298 #30
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
Pull reviewers statsStats of the last 30 days for lnd:
|
carlaKC
force-pushed
the
lint-7298
branch
3 times, most recently
from
3925639
to
f09f28c
Compare
We'll need to pack feature vectors for route blinding, so we pull the encoding/decoding out into separate functions (currently contained in ChannelType). Though it's more lines of code, we keep most of the ChannelType assertions so that we strictly enforce use of the alias.
This commit adds encoding and decoding for blinded route data blobs. TLV fields such as path_id (which are only used for the final hop) are omitted to minimize the change size.
carlaKC
force-pushed
the
lint-7298
branch
5 times, most recently
from
3b02fa7
to
720f879
Compare
Co-authored-by: Calvin Zachman <calvin.zachman@protonmail.com>
Add blinding points to update_add_htlc. This TLV will be set for nodes that are relaying payments in blinded routes that are _not_ the introduction node.
This commit adds an optional blinding point to payment descriptors and persists them in our HTLC's extra data. A get/set pattern is used to populate the ExtraData on our disk representation of the HTLC so that callers do not need to worry about the underlying storage detail.
When we have payments inside of a blinded route, we need to know the incoming amount to be able to back-calculate the amount that we need to forward using the forwarding parameters provided in the blinded route encrypted data. This commit adds the payment amount to our DecodeHopIteratorRequest so that it can be threaded down to payment forwarding information creation in later commits.
Blinding points will always be accompanied by encrypted data, so update the test to more accurately represent reality.
Update test to include the sphinx action to more closely represent reality. This will be required when we add more validation to the presence of a nextChanID field. A MoreHops action is chose because we're testing the case with a payload that contains forwarding info.
Provide valid hop payloads for tests cases that use TLV onion format.
Previously, we were using nextChanID to determine whether a hop payload is for the final recipient. This is no longer suitable in a route-blinding world where intermediate hops are allowed to have zero nextChanID TLVs (as this information is provided to forwarding nodes in their encrypted data). This commit updates payload reading to use the signal provided by sphinx that we are on the last packet, rather than implying it from the contents of a hop.
Previously, we'd use the value of nextChanID to infer whether a payload was for the final hop in a route. This commit updates our packing logic to explicitly signal to account for blinded routes, which allow zero value nextChanID in intermediate hops. This is a preparatory commit that allows us to more thoroughly validate payloads.
Fix our existing test to have a valid intermediate hop that will pass stricter validation. Previously, we did not specify a next channel for an intermediate hop (which violates bolt4).
Co-authored-by: Calvin Zachman <calvin.zachman@protonmail.com>
This commit introduces a blinding kits which abstracts over the operations required to decrypt, deserialize and reconstruct forwarding data from an encrypted blob of data included for nodes in blinded routes. The concept of a BlindingKey is separated into a separate struct so that it can be used independently of the kit (which is specifically used to process encrypted blobs). This abstraction will be used later to help determine how we handle errors.
When we have a HTLC that is part of a blinded route, we need to include the next ephemeral blinding point in UpdateAddHtlc for the next hop. The way that we handle the addition of this key is the same for introduction nodes and relaying nodes within the route.
If we received a payload with a blinding point set, our forwarding information should be set from the information in our encrypted blob. This behavior is the same for introduction and relying nodes in a blinded route.
Note: the itest is broken up into multiple commits to make it more readable, they can be squashed post-review.
We don't support receiving blinded in this PR - just intercept and settle instead. The HTLC's arrival on the interceptor indicates that it was successfully forwarded on a blinded hop.
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.
No description provided.