Add grace period for older channel parameters

[t-bast]

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.

[vincenzopalazzo]

ACK ce99310

[t-bast]

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

[renepickhardt]

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

[t-bast]

Done.

[vincenzopalazzo]

ACK 2d008dd

[carlaKC]

Looks good!

[Roasbeef]

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]

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]

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]

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]

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]

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