Skip to content
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

Add grace period for older channel parameters #1001

Merged
merged 1 commit into from
Jul 18, 2022

Conversation

t-bast
Copy link
Collaborator

@t-bast t-bast commented Jun 15, 2022

When a node creates a new channel_update to change its channel parameters, it will take some time to propagate through the network and payers may use older parameters. It is recommended to keep accepting older parameters for a while to improve payment latency and reliability. Eclair and Core Lightning already implement this.

Copy link
Contributor

@vincenzopalazzo vincenzopalazzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK ce99310

@t-bast
Copy link
Collaborator Author

t-bast commented Jun 20, 2022

Notes from the meeting: the spec should mention what a reasonable number is.

When a node creates a new `channel_update` to change its channel parameters,
it will take some time to propagate through the network and payers may use
older parameters. It is recommended to keep accepting older parameters for a
while to improve payment latency and reliability.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should define a number here? It seems 10 minutes are reasonable?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

When a node creates a new `channel_update` to change its channel parameters,
it will take some time to propagate through the network and payers may use
older parameters. It is recommended to keep accepting older parameters for a
while to improve payment latency and reliability.
Copy link
Contributor

@vincenzopalazzo vincenzopalazzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 2d008dd

Copy link
Contributor

@carlaKC carlaKC left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@Roasbeef
Copy link
Collaborator

Makes sense, I think some nodes also already do this. FWIW, lnd doesn't do this yet, but iiuc the main motivation here is better compatibility with route blinding (routes can be used for a longer period of time).

@t-bast
Copy link
Collaborator Author

t-bast commented Jun 30, 2022

While it also helps route blinding, it's really useful today as well to make up for delays in receiving channel_updates or a sender missing our latest channel_update. This is why cln and eclair have already implemented this a while ago regardless of route blinding.

@cdecker
Copy link
Collaborator

cdecker commented Jul 4, 2022

As rationale for the 10 minutes: the current network diameter is about 7, if every node has a staggered broadcast interval of 60 seconds, and we assume worst-case (i.e., they all synchronize their clocks, thus from receiving to forwarding we get exactly 60 seconds + 1/2 RTT of the link that it is forwarded over), we get a worst-case delay from emitting the channel_update to everybody receiving it of 7 minutes + 3.5 RTT. For some RTT < 0.85 minutes we are therefore sure the upadte has propagated throughout the entire network.

Offline nodes may of course come back up and not see the channel_update, however they have to handle outdated routing information anyway, so no additional failure surface is introduced.

@tnull
Copy link
Contributor

tnull commented Jul 4, 2022

As rationale for the 10 minutes: the current network diameter is about 7, if every node has a staggered broadcast interval of 60 seconds, and we assume worst-case (i.e., they all synchronize their clocks, thus from receiving to forwarding we get exactly 60 seconds + 1/2 RTT of the link that it is forwarded over), we get a worst-case delay from emitting the channel_update to everybody receiving it of 7 minutes + 3.5 RTT. For some RTT < 0.85 minutes we are therefore sure the upadte has propagated throughout the entire network.

Offline nodes may of course come back up and not see the channel_update, however they have to handle outdated routing information anyway, so no additional failure surface is introduced.

The 10 minutes would also make sense according to our real-world measurements, which indicate that 50% of nodes are reached in the first ~5 minutes and 95% in ~12 minutes (cf. https://arxiv.org/pdf/2205.12737.pdf, p. 6).

@ProofOfKeags
Copy link
Contributor

the current network diameter is about 7

How do we know what the gossip networks diameter is? Isn't the p2p linkage much more dynamic than the channel graph? Or is that network diameter the measure of the channel graph?

@cdecker
Copy link
Collaborator

cdecker commented Jul 9, 2022

the current network diameter is about 7

How do we know what the gossip networks diameter is? Isn't the p2p linkage much more dynamic than the channel graph? Or is that network diameter the measure of the channel graph?

Good catch, I implicitly assumed the gossip network to be representative, which isn't quite true, but can serve as an upper bound. Any real world end-to-end latency would be lower than this estimate

@niftynei niftynei merged commit 074a71f into lightning:master Jul 18, 2022
@t-bast t-bast deleted the fees-grace-period branch October 27, 2022 10:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants