Archives/lnbook
2
0
Fork 0
mirror of https://github.com/lnbook/lnbook synced 2024-11-01 03:20:53 +00:00
Code Issues Projects Releases Wiki Activity

Edited 11_gossip_channel_graph.asciidoc with Atlas code editor

Browse Source
This commit is contained in:
kristen@oreilly.com 2021-10-15 06:41:22 -07:00
parent b02a7d9216
commit 951127d7cb
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
11_gossip_channel_graph.asciidoc
View File

@ -91,7 +91,7 @@ existing Internet protocols to maintain and distribute a set of bootstrapping pe
Similar to the Bitcoin protocol, the primary initial peer discovery mechanism used in the Lightning Network happens via DNS. As initial peer discovery is a critical and universal task for the network, the process has been _standardized_ in https://github.com/lightningnetwork/lightning-rfc/blob/master/10-dns-bootstrap.md[BOLT #10 - DNS Bootstrap].
==== Dns Bootstrapping
==== DNS Bootstrapping
The https://github.com/lightningnetwork/lightning-rfc/blob/master/10-dns-bootstrap.md[BOLT #10] document describes a standardized way of implementing peer
discovery using the Domain Name System (DNS). Lightning's flavor of DNS based bootstrapping uses up to 3 distinct record types:
@ -217,7 +217,7 @@ peer and established its first connection! Now we can begin the second phase of
First, we'll explore more of the intricacies of BOLT 10 itself to take a deeper look into how things work under the hood.
==== Srv Query Options
==== SRV Query Options
The https://github.com/lightningnetwork/lightning-rfc/blob/master/10-dns-bootstrap.md[BOLT #10] standard is highly extensible due to its usage of nested
sub-domains as a communication layer for additional query options. The
@ -285,7 +285,7 @@ themselves _authenticated_ allowing a 3rd party to ensure that the owner of a ch
With the high level structure of the channel graph laid out, we'll now dive down into the precise structure of each of the three messages used to gossip the channel graph. We'll also explain how one can also _verify_ each message and component of the channel graph.
[[node_announcement]]
==== The Node_Announcement Message
==== The node_announcement Message
First, we have the +node_announcement+ message, which serves two primary
purposes:
@ -333,7 +333,7 @@ Validating an incoming +node_announcement+ is straight forward. The following as
* The included +alias+ bytes MUST be a valid UTF-8 string.
==== The Channel_Announcement Message
==== The channel_announcement Message
Next, we have the +channel_announcement+ message, which is used to _announce_ a new _public_ channel to the wider network. Note that announcing a channel is _optional_. A channel only needs to be announced if it is intended to be used for routing by the Lightning network. Active routing nodes may wish to announce all their channels. However, certain nodes like mobile nodes likely don't have the
uptime or desire to be an active routing node. As a result, these
@ -431,7 +431,7 @@ Finally, the verifier will reconstruct the multisig script from +bitcoin_key_1+
The verifier has now independently verified that the payment channel in the announcement is funded and confirmed on the Bitcoin blockchain!
==== The Channel_Update Message
==== The channel_update Message
The third and final message used in the gossip protocol is the +channel_update+ message. Two of these are generated for each payment channel (one by each channel partner) announcing their routing fees, timelock expectations and capabilities.