-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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: follow ups #8976
Conversation
Important Review skippedAuto reviews are limited to specific labels. Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
757913b
to
b5960f3
Compare
127b1d9
to
77a9983
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.
Great follow ups!
Re giving CLI/RPC clients a better error messages, two options come to mind:
- Modify
zpay32.Decode
to accept an optionallnwire.FeatureVector
of the features that we understand. After decode, it checks that new optional field to know if it should error out or not. For older clients, this can at least print that they don't understand feature bitYYY
. - Do it deeper in the router.
The first option seems preferable, as then it'll error out at the earliest layer possible in the RPC server.
routing/pathfind.go
Outdated
@@ -1253,6 +1257,12 @@ func processNodeForBlindedPath(g Graph, node route.Vertex, | |||
return nil, false, nil | |||
} | |||
|
|||
// If we have explicitly been told to ignore this node for blinded paths | |||
// then we skip it too. | |||
if restrictions.nodeOmissionSet[node] { |
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.
Do we also need to mark the node as visited to avoid repeatedly relaxing into it?
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.
good idea
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.
ah actually - i think let's leave as is cause alreadyVisited
is used to get the idea of how long this path currently is. So adding this node in there will result in incorrect path length check
ah yeah that is a great idea! incoming.... The only thing is that this nicer error message will only be useful for a future feature bit & not for route blinding cause nodes updating to this version will understand route blinding. |
77a9983
to
766113a
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.
cool - updated!
also added logging of the chosen paths . Example:
[DBG] BLPT: Route selected for blinded path: [02cfe333599d4ecbe15673981b66121369dde97c5a72b6ba261f03cc2f96dff2ce (intro node)]--<485984139673600>-->[0360771d81f5a3d4bdc5cac0c46b946a572684ae66b8d30ab1774b18d9219d6f36]--->[dummy hop]
routing/pathfind.go
Outdated
@@ -1253,6 +1257,12 @@ func processNodeForBlindedPath(g Graph, node route.Vertex, | |||
return nil, false, nil | |||
} | |||
|
|||
// If we have explicitly been told to ignore this node for blinded paths | |||
// then we skip it too. | |||
if restrictions.nodeOmissionSet[node] { |
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.
ah actually - i think let's leave as is cause alreadyVisited
is used to get the idea of how long this path currently is. So adding this node in there will result in incorrect path length check
f248efd
to
7fd98ce
Compare
7fd98ce
to
f2f51c4
Compare
f2f51c4
to
3a4165a
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.
Looks great 🔥, nice additions, needs a clarification concerning a test case and maybe some safety checks concerning the cli flags.
3a4165a
to
1012d14
Compare
Fix the blinded path probability sorting function. Also fix the test assertion function.
since `AddInvoiceData` is config _per invoice_ where as `AddInvoiceConfig` is config for the invoice server itself and so pretty much should stay the same for the lifetime of LND. This change sets us up for moving some of the blinded path config options to be changeable per AddInvoice call rather that having fixed config values in the config file.
Extend the configurability of blinded paths in invoices by adding the ability to change the global config options on a per-RPC basis.
In this commit, we adjust BuildBlindedPaymentPaths to only error out completely if none of the paths it received from FindRoutes resulted in a usable blinded path.
This commit adds two functional options to the zpay32.Decode function. `WithKnownFeatureBits` allows the caller to overwrite the default set of known feature bits used by the function. `WithErrorOnUnknownFeatureBit` allows the caller to instruct the function to error out if the invoice that is decoded contaijns unknown feature bits. We then use this new error-out option from the `rpcServer`'s `extractPaymentIntent` method.
In this commit, we log selected blinded paths.
1012d14
to
d47ff3a
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 🎉
so that they dont clash with the htlc-endorsement feature bits.
Heh, yeah good point! So then this change is more for w/e future instance where we added more required feature bits. In theory we could also back port the new feature bit logic to older versions, but we haven't yet solidified our policy for that. |
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 🐊
@@ -746,7 +746,7 @@ func (r *ChannelRouter) FindBlindedPaths(destination route.Vertex, | |||
|
|||
// Sort the routes based on probability. | |||
sort.Slice(routes, func(i, j int) bool { | |||
return routes[i].probability < routes[j].probability | |||
return routes[i].probability > routes[j].probability |
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.
Ah sure, increasing order of prob!
NodeOmissionList
so that we can force certain nodes to not be included in our blinded pathsFixes #8965