-
Notifications
You must be signed in to change notification settings - Fork 404
Move to block-based channel disable updates #2175
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
Milestone
Comments
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Apr 18, 2023
We correctly send out a gossip channel disable update after one full time tick being down (1-2 minutes). This is pretty nice in that it avoids nodes trying to route through our nodes too often if they're down. Other nodes have a much longer time window, causing them to have much less aggressive channel disables. Sadly, at one minute it's not super uncommon for tor nodes to get disabled (once a day or so on two nodes I looked at), and this causes the lightning terminal scorer to consider the LDK node unstable (even though it's the one doing the disabling - so is online). This causes user frustration and makes LDK look bad (even though it's probably failing fewer payments). Given this, and future switches to block-based `channel_update` timestamp fields, it makes sense to go ahead and switch to delaying channel disable announcements for 10 minutes. This puts us more in line with other implementations and reduces gossip spam, at the cost of less reliable payments. Fixes lightningdevkit#2175, at least the currently visible parts.
optout21
pushed a commit
to optout21/rust-lightning
that referenced
this issue
Jul 24, 2023
We correctly send out a gossip channel disable update after one full time tick being down (1-2 minutes). This is pretty nice in that it avoids nodes trying to route through our nodes too often if they're down. Other nodes have a much longer time window, causing them to have much less aggressive channel disables. Sadly, at one minute it's not super uncommon for tor nodes to get disabled (once a day or so on two nodes I looked at), and this causes the lightning terminal scorer to consider the LDK node unstable (even though it's the one doing the disabling - so is online). This causes user frustration and makes LDK look bad (even though it's probably failing fewer payments). Given this, and future switches to block-based `channel_update` timestamp fields, it makes sense to go ahead and switch to delaying channel disable announcements for 10 minutes. This puts us more in line with other implementations and reduces gossip spam, at the cost of less reliable payments. Fixes lightningdevkit#2175, at least the currently visible parts.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We correctly send out a gossip channel disable update after one full time tick being down (1-2 minutes). This is pretty nice in that it avoids nodes trying to route through our nodes too often if they're down. Other nodes have a much longer time window, causing them to have much less aggressive channel disables. Sadly, at one minute it's not super uncommon for tor nodes to get disabled (once a day or so on two nodes I looked at), and this causes the lightning terminal scorer to consider the LDK node unstable (even though it's the one doing the disabling - so is online). This causes user frustration and makes LDK look bad (even though it's probably failing fewer payments).
With taproot gossip we'll soon only be able to announce an update once per block, so at least for taproot channels we'll have to reduce the rate anyway.
Given the above I think we should go ahead and make this change for all channels. Not sure what the exact policy should be (we should stay maybe 10 blocks behind the tip and only update if we have "room", but maybe we should default to leaving a channel disabled if the peer is flapping when we run out of room? Just reducing our disable time to 5 minutes or so?).
The text was updated successfully, but these errors were encountered: