routing: fix mc blinded path behaviour. #9316
Open
+24
−7
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
|
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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
ziggie1984
force-pushed
the
fix-blindedpath-mc
branch
from
d2c031e
to
caee111
Compare
ziggie1984
force-pushed
the
fix-blindedpath-mc
branch
2 times, most recently
from
c74d2c0
to
2facd58
Compare
|
maybe we should add an itest ? |
ellemouton
reviewed
Nov 28, 2024
routing/result_interpretation.go
Outdated
Comment on lines
523
to
524
| // route we swap the target pubkey for a general one | ||
| // so that multi-path payment can be attempted. However |
There was a problem hiding this comment.
it isnt super clear to me from the comment what the issue is/was. Is it that we only want to penalise one path instead of all the paths? why not just use the real (pre swap) final key & penalise that?
There was a problem hiding this comment.
We currently do use the real-path-pubkey, the problem arises that we will not use this information during pathfinding hence we will try to reattempt paths which already failed with the invalid blinding error. So that's why I propose penalizing the whole path which makes it bullet-proof.
There was a problem hiding this comment.
I don't see the problem yet, could you specify a reproduction scenario (and logs with amounts)? The last hop (swapped) pubkey should be stable over a payment, right? So penalizing the last hop pair should be in effect even if further partial attempts are made. I can see though that the amount will be split often and the route will be re-attempted until the min shard size is reached
There was a problem hiding this comment.
the setup is pretty simple, just create a blinded path where the payment fails in the blinded path. LND will retry the payment until timeout because the wrong pair is penalized in the MC.
There was a problem hiding this comment.
LND will also not split the amount because it always find the same route.
There was a problem hiding this comment.
ok, yes I see it now thanks for the examples, in pathfinding we use the swapped pubkey T for Z (X, T), but when reporting to mission control we use the original route and therefore we punish (X, Z). I think we can fix it like it is done in this PR.
However, as noted in the comments in the lines above this change, we would fail a payment that has for example two single-hop hop hints after we fail to send over one of them. As noted in the comment, this was ok for non-mpp scenarios, but we support mpp now. So I think the cleanest fix would be to add a dummy hop to the single-hop hints such that we have an extension like [(X,Z), (Z,T)] and a search a path to T. If we make T static, we could even reuse those mc reports for the same blinded route (not sure if there's an application). The dummy hop would need to be transported via the route to reporting of mission control.
There was a problem hiding this comment.
That actually seems like the quick non-mpp solution, swap in a static pubkey before pathfinding and swap it in again when reporting a failure of the blinded route?
|
After a discussion with Elle we decided to only punish the first PubKey after the intropoint and create an issue which makes sure blinded route mc data is not persistent in the db but rather only held in memory and removed as soon as the payment is done. |
Because we hot swap the target public key when sending to a blinded path (pathfinding logic to enable mpp support for blinded payments) we penalize the first hop after the intro node. Also added a TODO which only keeps the mc data for blinded paths in memory and discards it afterwards, because this data will never be reused as soon as the invoice is expired or settled.
ziggie1984
force-pushed
the
fix-blindedpath-mc
branch
from
2facd58
to
bff6e2c
Compare
|
some logs of the problem, so the problem is the wrong channel-pair is punished and we will always use the same path: and from the cli view: |
|
same for a bigger amount: |
|
After discussions with @bitromortac we decided to change the approach: We are going to introduce a static target key (via a nums Point) so that no node can come up with the corresponding private key to create valid routes. When searching for paths or reporting an error in a blinded route we will use this key to persist the change. This will make it easy for us to clear the current MC-Store from blinded path data when we introduce the new blinded path logic where we won't persist blinded path MC data. |
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.
Because we hot swap the target public key when sending to a
blinded path we need to penalize all nodes after the introduction
point.
We could also just penalize the first node after the introduction node, however that would mean we would do a bit of more pathfinding work and only fail after considering the rest of the blinded path. I think it is not super critical to have this bit more data persistent in memory.