mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

Add grace period for older channel parameters

Browse Source 
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.
This commit is contained in:
t-bast 2022-06-15 17:18:24 +02:00 committed by neil saitug
parent 2ecc091f34
commit 074a71f003
1 changed files with 15 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
07-routing-gossip.md
View File

@ -491,6 +491,8 @@ The origin node:
- MUST set `fee_proportional_millionths` to the amount (in millionths of a
satoshi) it will charge per transferred satoshi.
- SHOULD NOT create redundant `channel_update`s
- If it creates a new `channel_update` with updated channel parameters:
- SHOULD keep accepting the previous channel parameters for 10 minutes
The receiving node:
- if the `short_channel_id` does NOT match a previous `channel_announcement`,
@ -540,14 +542,14 @@ makes sense to have it be a UNIX timestamp (i.e. seconds since UTC
1970-01-01). This cannot be a hard requirement, however, given the possible case
of two `channel_update`s within a single second.
It is assumed that more than one `channel_update` message changing the channel
parameters in the same second may be a DoS attempt, and therefore, the node responsible
for signing such messages may be blacklisted. However, a node may send a same
`channel_update` message with a different signature (changing the nonce in signature
signing), and hence fields apart from signature are checked to see if the channel
parameters have changed for the same timestamp. It is also important to note that
ECDSA signatures are malleable. So, an intermediate node who received the `channel_update`
message can rebroadcast it just by changing the `s` component of signature with `-s`.
It is assumed that more than one `channel_update` message changing the channel
parameters in the same second may be a DoS attempt, and therefore, the node responsible
for signing such messages may be blacklisted. However, a node may send a same
`channel_update` message with a different signature (changing the nonce in signature
signing), and hence fields apart from signature are checked to see if the channel
parameters have changed for the same timestamp. It is also important to note that
ECDSA signatures are malleable. So, an intermediate node who received the `channel_update`
message can rebroadcast it just by changing the `s` component of signature with `-s`.
This should however not result in the blacklist of the `node_id` from where
the message originated.
@ -565,6 +567,11 @@ the channel when the peer reestablishes contact. Because gossip
messages are batched and replace previous ones, the result may be a
single seemingly-redundant update.
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
at least 10 minutes to improve payment latency and reliability.
## Query Messages
Negotiating the `gossip_queries` option via `init` enables a number