mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-10 09:10:07 +01:00
Code Issues Projects Releases Wiki Activity

BOLT #7: introduce term "gossip messages" to refer to channel_announcement/channel_update/node_announcement.

Browse source 
This makes discussing them simpler for the next patch.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2018-06-27 06:18:44 +09:30
parent a8207ec316
commit aab92b15b7
1 changed files with 11 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
07-routing-gossip.md
View file

@ -7,7 +7,7 @@ Node and channel discovery serve two different purposes:
- Channel discovery allows the creation and maintenance of a local view of the network's topology, so that a node can discover routes to desired destinations. - Channel discovery allows the creation and maintenance of a local view of the network's topology, so that a node can discover routes to desired destinations.
- Node discovery allows nodes to broadcast their ID, host, and port, so that other nodes can open connections and establish payment channels with them. - Node discovery allows nodes to broadcast their ID, host, and port, so that other nodes can open connections and establish payment channels with them.
To support channel discovery, peers in the network exchange To support channel discovery, three *gossip messages* are supported. Peers in the network exchange
`channel_announcement` messages containing information regarding new `channel_announcement` messages containing information regarding new
channels between the two nodes. They can also exchange `channel_update` channels between the two nodes. They can also exchange `channel_update`
messages, which update information about a channel. There can only be messages, which update information about a channel. There can only be
@ -77,7 +77,7 @@ A recipient node:
## The `channel_announcement` Message ## The `channel_announcement` Message
This message contains ownership information regarding a channel. It ties This gossip message contains ownership information regarding a channel. It ties
each on-chain Bitcoin key to the associated Lightning node key, and vice-versa. each on-chain Bitcoin key to the associated Lightning node key, and vice-versa.
The channel is not practically usable until at least one side has announced The channel is not practically usable until at least one side has announced
its fee levels and expiry, using `channel_update`. its fee levels and expiry, using `channel_update`.
@ -210,7 +210,7 @@ nodes that do not understand them.
## The `node_announcement` Message ## The `node_announcement` Message
This message allows a node to indicate extra data associated with it, in This gossip message allows a node to indicate extra data associated with it, in
addition to its public key. To avoid trivial denial of service attacks, addition to its public key. To avoid trivial denial of service attacks,
nodes not associated with an already known channel are ignored. nodes not associated with an already known channel are ignored.
@ -349,7 +349,7 @@ through this channel. Each uses the 8-byte channel shortid that matches the
channel it's on (origin or final). A node can do this multiple times, in channel it's on (origin or final). A node can do this multiple times, in
order to change fees. order to change fees.
Note that the `channel_update` message is only useful in the context Note that the `channel_update` gossip message is only useful in the context
of *relaying* payments, not *sending* payments. When making a payment of *relaying* payments, not *sending* payments. When making a payment
`A` -> `B` -> `C` -> `D`, only the `channel_update`s related to channels `A` -> `B` -> `C` -> `D`, only the `channel_update`s related to channels
`B` -> `C` (announced by `B`) and `C` -> `D` (announced by `C`) will `B` -> `C` (announced by `B`) and `C` -> `D` (announced by `C`) will
@ -498,8 +498,8 @@ The final node:
for its peers. for its peers.
An endpoint node: An endpoint node:
- SHOULD flush outgoing announcements once every 60 seconds, independently of - SHOULD flush outgoing gossip messages once every 60 seconds, independently of
the arrival times of announcements. the arrival times of the messages.
- Note: this results in staggered announcements that are unique (not - Note: this results in staggered announcements that are unique (not
duplicated). duplicated).
- MAY re-announce its channels regularly. - MAY re-announce its channels regularly.
@ -510,14 +510,14 @@ An endpoint node:
### Rationale ### Rationale
Once the announcement has been processed, it's added to a list of outgoing Once the gossip message has been processed, it's added to a list of outgoing
announcements, destined for the processing node's peers, replacing any older messages, destined for the processing node's peers, replacing any older
updates from the origin node. This list of announcements will be flushed at updates from the origin node. This list of gossip messages will be flushed at
regular intervals: such a store-and-delayed-forward broadcast is called a regular intervals: such a store-and-delayed-forward broadcast is called a
_staggered broadcast_. Also, such batching of announcements forms a natural rate _staggered broadcast_. Also, such batching forms a natural rate
limit with low overhead. limit with low overhead.
The sending of all announcements on reconnection is naive, but simple, The sending of all gossip on reconnection is naive, but simple,
and allows bootstrapping for new nodes as well as updating for nodes that and allows bootstrapping for new nodes as well as updating for nodes that
have been offline for some time. have been offline for some time.