-
Notifications
You must be signed in to change notification settings - Fork 895
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
Recover from unparseable onion replies from routing failures somehow #868
Labels
Comments
ZmnSCPxj
changed the title
Feature: Recover from unparseable onion replies from routing failures somehow
Enhancement: Recover from unparseable onion replies from routing failures somehow
Feb 1, 2018
cdecker
changed the title
Enhancement: Recover from unparseable onion replies from routing failures somehow
Recover from unparseable onion replies from routing failures somehow
Feb 1, 2018
I like the idea of temporarily disabling one channel, we could just have a timer that re-enables the channel after a few seconds, or once the route succeeded. |
I sketch this here.
|
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Feb 7, 2018
… channels. Fixes: ElementsProject#868 Not pretty, but workable.
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Feb 7, 2018
… channels. Fixes: ElementsProject#868 Not pretty, but workable.
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Feb 7, 2018
… channels. Fixes: ElementsProject#868 Not pretty, but workable.
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Feb 7, 2018
… channels. Fixes: ElementsProject#868 Not pretty, but workable.
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Feb 7, 2018
… channels. Fixes: ElementsProject#868 Not pretty, but workable.
rustyrussell
pushed a commit
that referenced
this issue
Feb 8, 2018
… channels. Fixes: #868 Not pretty, but workable.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unparseable onion replies are currently not reported to gossipd. This means if we get an unparseable onion reply from routing failure, we do not update the gossipd routemap and would get the same route again.
One simple solution would be to simply randomly select one of the nodes on the route and deactivate its channels (or if that seems too harsh, just one of the channels on the route). This will at least make gossipd return a different route afterwards, at least guaranteeing some sort of forward progress. If we guessed wrong,there is the chance the same unparseable node gets selected again, but at least we can get to try some other route.
xref. #638 (comment)
The text was updated successfully, but these errors were encountered: