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

diverse minor typo

Browse Source
This commit is contained in:
Frnk 2021-04-05 17:26:32 +02:00
parent 9852fa8592
commit c51a184815
1 changed files with 23 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
gossip.asciidoc
View File

@ -8,11 +8,11 @@ Thus the sender has to be aware of the Channel Graph.
The channel graph is the interconnected set of publicly advertised channels (more on that later), and the nodes that these channels interlink.
As channels are backed by a funding transaction that is happening on chain one might falsely believe that Lightning Nodes could just extract the existing channels from the Bitcoin Blockchain.
However this only possible to a certain extend.
The Funding transactions are Pay to Whitness Script addresses and the nature of the script will only be revealed once the funding transaction output is spent.
The Funding transactions are Pay to Witness Script addresses and the nature of the script will only be revealed once the funding transaction output is spent.
Even if the nature of the script was known we emphasize that not all 2 - of - 2 multisignature scripts correspond to payment channels.
Since not even every Pay to Whitness Script address that we see in the Bitcoin Blockchain corresponds to a payment channel this approach is not helpful.
Since not even every Pay to Witness Script address that we see in the Bitcoin Blockchain corresponds to a payment channel this approach is not helpful.
There are actually more reasons why looking at the Bitcoin Blockchain might not be helpful.
For example on the Lightnign Network the Bitcoin keys that are used for signing are rotated by the nodes for every channel and update.
For example on the Lightning Network the Bitcoin keys that are used for signing are rotated by the nodes for every channel and update.
Thus even if we could reliably detect funding transactions on the Bitcoin Blockchain we would not know which two nodes on the Lightning Network own that particular channel.
Thus we could node create the Channel Graph that would be used to create candidate paths during the payment delivery via onion routing.
@ -20,11 +20,11 @@ The Lightning Network solves the afore mentioned problem by implementing a gossi
Gossip protocols are typical for peer 2 peer networks and are being used so that nodes can share information with other nodes without talking to those other nodes directly.
For that Lightning Nodes open encrypted peer 2 peer connections to each other and share novel information that they have received from other peers.
As soon as a node wants to share some information - for example about a newly created channel - it sends a message to all its peers.
Uppon receiving a message a node decides if the received message was novel and if so it will forward the information to its peers.
Upon receiving a message a node decides if the received message was novel and if so it will forward the information to its peers.
In this way if the peer 2 peer network is connected all new information that is necessary for the operation of the network will eventually be propagated to all other peers.
Obviously if a new peer initially wants to join the network it needs to know some other peers on the Network initially.
Only then the new peer could connect to them in order to learn about the existance of other peers.
Only then the new peer could connect to them in order to learn about the existence of other peers.
In this chapter, we'll explore exactly _how_ Lightning nodes discover each
other, and also the channel graph itself.
When most refer to the _network_ part
@ -84,7 +84,7 @@ node that wishes to join the network as he sets out on his journey to which cons
. discovery a set of bootstrap peers.
. download and validate the channel graph.
. begin the process of ongoing maintainance of the channel graph itself.
. begin the process of ongoing maintenance of the channel graph itself.
### P2P Boostrapping
@ -269,7 +269,7 @@ In the above command, we've queried the server so we can obtain an `IPv4`
address for our target node. Now that we have both the raw public key _and_ IP
address, we can connect to the node using the `brontide` transport protocol at:
`026c64f5a7f24c6f7f0e1d6ec877f23b2f672fb48967c2545f227d70636395eaf3@X.X.X.X`.
Querying for the curent `A` record for a given node can also be used to look up
Querying for the current `A` record for a given node can also be used to look up
the _latest_ set of addresses for a given node. Such queries can be used to
more quickly (compared to waiting on gossip as we'll cover later) sync the
latest addressing information for a node.