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

BOLT 7: be more aggressive about sending our own gossip.

Browse Source 
As more nodes on the network use timestamp_filter to block gossip
floods, we've seen some propagation problems.  This should avoid it
(and is implemented now by c-lightning).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2019-10-14 13:59:23 +10:30 committed by Christian Decker
parent 0bb69d3a37
commit 458b0d34e1
1 changed files with 13 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
07-routing-gossip.md
View File

@ -828,9 +828,11 @@ The receiver:
equal to `first_timestamp`, and less than `first_timestamp` plus
`timestamp_range`.
- MAY wait for the next outgoing gossip flush to send these.
- SHOULD restrict future gossip messages to those whose `timestamp`
is greater or equal to `first_timestamp`, and less than
`first_timestamp` plus `timestamp_range`.
- SHOULD send gossip messages as it generates them regardless of `timestamp`.
- Otherwise (relayed gossip):
- SHOULD restrict future gossip messages to those whose `timestamp`
is greater or equal to `first_timestamp`, and less than
`first_timestamp` plus `timestamp_range`.
- If a `channel_announcement` has no corresponding `channel_update`s:
- MUST NOT send the `channel_announcement`.
- Otherwise:
@ -855,6 +857,12 @@ is simple to implement.
In the case where the `channel_announcement` is nonetheless missed,
`query_short_channel_ids` can be used to retrieve it.
Nodes can use `timestamp_filter` to reduce their gossip load when they
have many peers (eg. setting `first_timestamp` to `0xFFFFFFFF` after the
first few peers, in the assumption that propagation is adequate).
This assumption of adequate propagation does not apply for gossip messages
generated directly by the node itself, so they should ignore filters.
## Initial Sync
If a node requires an initial sync of gossip messages, it will be flagged
@ -872,7 +880,7 @@ interactions with them.
A node:
- if the `gossip_queries` feature is negotiated:
- MUST NOT relay any gossip messages unless explicitly requested.
- MUST NOT relay any gossip messages it did not generate itself, unless explicitly requested.
- otherwise:
- if it requires a full copy of the peer's routing state:
- SHOULD set the `initial_routing_sync` flag to 1.
@ -904,7 +912,7 @@ A receiving node:
A node:
- if the `gossip_queries` feature is negotiated:
- MUST not send gossip until it receives `gossip_timestamp_filter`.
- MUST not send gossip it did not generate itself, until it receives `gossip_timestamp_filter`.
- SHOULD flush outgoing gossip messages once every 60 seconds, independently of
the arrival times of the messages.
- Note: this results in staggered announcements that are unique (not