-
Notifications
You must be signed in to change notification settings - Fork 339
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
Avoid applying onion's channel updates in an observable way #2666
Avoid applying onion's channel updates in an observable way #2666
Conversation
Currently in draft until the approach is clarified. I already started some commits including the |
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2666 +/- ##
==========================================
- Coverage 88.98% 88.94% -0.04%
==========================================
Files 112 112
Lines 87632 87663 +31
Branches 87632 87663 +31
==========================================
- Hits 77978 77975 -3
- Misses 7421 7441 +20
- Partials 2233 2247 +14
☔ View full report in Codecov by Sentry. |
e6ed6af
to
5485d1b
Compare
Yea, this makes sense to me. Lets just remove the |
Mh, not sure if we want to keep the ability to manually apply updates to a graph around for users knowing what they doing? But if we want to remove it, I think it may make sense to also drop |
I mean, I think (a) we think its a terrible idea to apply the update, and would be a lot of work to do so safely (you'd probably have to keep a second copy of the network graph), and (b) we expect to receive the update via the normal gossip network soon anyway, so its not like we're missing out for too long, and (c) we score the channel negatively cause the payment failed (I hope, need to double-check that?) so we shouldn't be retrying over the same channel soon even for a new payment, and (d) probably the network updates will go away in the spec cause its such a bad issue anyway.... I don't really think its worth keeping a bunch of code around for such a rarely-useful case, much better to have less code :) I do think we should keep |
Alright, makes sense.
Hum, but they'd likely receive gossip data as Given that it's really just a wrapper type used for the one purpose we're about to drop, it's really tempting to drop all that associated code. |
Oh, duh, yea. |
Yea, I'm just a bit torn on removing from perm failures - it does seem like something worth doing given we don't currently look at the chain to remove after the funding outpoint is spent (and rely on timeouts of the channel_updates). The timeouts are after a week or two, though. |
Mh, will think about that once more, but currently have no strong opinion on it. I now pushed a commit removing the |
We introduce a new `NetworkGraph::verify_channel_update` method that allows to check whether an update would be applied by `update_channel`.
e64a293
to
8d7aa35
Compare
If we receive a channel update from an intermediary via a failure onion we shouldn't apply them in a persisted and network-observable way to our network graph, as this might introduce a privacy leak. Here, we therefore avoid applying such updates to our network graph.
8d7aa35
to
1c35255
Compare
Alright, after more and more backpedaling I now pushed an MVP that just skips application of the |
Fixes #2598.
If we receive a channel update from an intermediary via a failure onion we shouldn't apply them in a persisted and network-observable way to our network graph, as this might introduce a privacy leak.
Here, we therefore avoid applying such updates to our network graph.