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

comma separation

Browse Source
This commit is contained in:
Patrick Lemke 2020-02-20 17:51:58 +01:00
parent f7df2f5cd3
commit 85f5e4de32
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
ch03.asciidoc
View File

@ -290,9 +290,9 @@ While this method could be fully executed faster than the good and the bad way t
Every payment on the Lightning Network starts with a person who wants to receive bitcoins issuing an invoice.
The main reason for this process is that it helps to make the payment process over a path of payement channels atomic.
Atomic means that no node on the path can decide to take the money that is being routed and stop the routing process.
The payment will either be transfered successfully through the path of nodes or will not be delivered.
There are no such things as a partial payment or a half successfull payment.
While Lightning Nodes usually use the encrypted communication channels over the peer to peer network to exchange information, invoices are being transfered via a second communication channel.
The payment will either be transferred successfully through the path of nodes or will not be delivered.
There are no such things as a partial payment or a half successful payment.
While Lightning Nodes usually use the encrypted communication channels over the peer to peer network to exchange information, invoices are being transferred via a second communication channel.
This could be via a Webservice or Email.
Invoices are usually encoded either as long bech32 strings or as QR codes which enables them to be easily scanned by smartphones.
Obviously the invoices contains the amount of bitcoin that is requested and a signature of the payee.
@ -310,7 +310,7 @@ We note that this is not an additional security assumption for Bitcoin as the se
Invoices can encode some other useful meta data.
For example a short description.
In case a user has several invoices to pay, the user can read the description and make sure what the invoice was about.
As payment channels do not need to be publically announced, the payee can also provide some private channels as routing hints to the invoice.
As payment channels do not need to be publicly announced, the payee can also provide some private channels as routing hints to the invoice.
These hints can also be used for public channels to point to those channels on which the payee has enough inbound liquidity to actually receive the amount.
In case the payer's Lightning node is not able to send the payment over the Lightning Network, invoices can also include a fallback address.
We would however always recommend to open a new payment channel instead of doing an on chain transaction that does not add an additional payment channel.
@ -318,7 +318,7 @@ Invoices also have an expiry time so that the payee can delete the preimage afte
=== Delivering the payment
You have already learnt that payments start with the payee creating an invoice which includes a Payment Hash to make sure that payments are atomic and that no one on the path of payment channels can withold the transferred money to their benefit.
You have already learnt that payments start with the payee creating an invoice which includes a Payment Hash to make sure that payments are atomic and that no one on the path of payment channels can withhold the transferred money to their benefit.
In this section we will dive into the ideas and methods that are being used to deliver a payment over the Lightning Network and utilize everything that we have used so far.
We need to introduce one missing protocol of the Lightning Network which is the gossip protocol.
@ -374,7 +374,7 @@ The user might only realize that probing is taking place if the payment is not g
====
On the Internet we use the internet protocol and the IP forwarding algorithm to forward internet packages from the sender to the destination.
While the TCP/IP protocol stack allows reliable communication by resending packages that are not acknowledged this mechanism could not be reused directly in the Lightning Network.
A payment that is not being forwarded would effectivly mean that the money was stolen by a router and the sender cannot just send out another payment.
A payment that is not being forwarded would effectively mean that the money was stolen by a router and the sender cannot just send out another payment.
While the routing protocol together with the Border Gateway Protocol which are used for data and information transport on the internet have the really nice property of allowing the internet hosts to collaboratively find a path for the information through the internet, we cannot reuse and adopt this protocol for forwarding payments on the Lightning Network.
====
@ -384,7 +384,7 @@ This includes which public payment channels are connecting nodes, which capacity
==== Onion routing
If the sending node of a payment has selected a path that is supposed to be used to make the payment the Lightning Network uses an onion routing scheme similar to the famous TOR-network.
If the sending node of a payment has selected a path that is supposed to be used to make the payment, the Lightning Network uses an onion routing scheme similar to the famous TOR-network.
The routing scheme is called the SPHINX mixformat and will be explained in detail in a later chapter.
For now we want to focus on its properties for the transport of payments which we also call onions.