Add grace period for older channel parameters #1001
Conversation
|
Notes from the meeting: the spec should mention what a reasonable number is. |
07-routing-gossip.md
Outdated
| 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. |
There was a problem hiding this comment.
Maybe we should define a number here? It seems 10 minutes are reasonable?
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.
t-bast
force-pushed
the
fees-grace-period
branch
from
ce99310
to
2d008dd
Compare
|
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). |
|
While it also helps route blinding, it's really useful today as well to make up for delays in receiving |
|
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 Offline nodes may of course come back up and not see the |
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). |
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 |
When a node creates a new
channel_updateto 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.