Merge branch 'develop' into lint

02_getting_started.asciidoc

@@ -92,7 +92,7 @@ Alice uses an Android device and will use the Google Play Store to download and
 .Eclair Mobile in the Google Play Store
 image:images/eclair-playstore.png["Eclair wallet in the Google Play Store"]
 
-Alice notices a few different elements on this page, that help her ascertain that this is, most likely, the correct "Eclair Mobile" wallet she is looking for. Firstly, the organization "ACINQ" footnote:[ACINQ: Developers of the Eclair Mobile Lightning wallet (https://acinq.io/).] is listed as the developer of this mobile wallet, which Alice knows from her research is the correct developer. Secondly, the wallet has been installed "10,000+" times and has more than 320 positive reviews. It is unlikely this is a rogue app that has snuck into the Play Store. Satisfied by these findings, Alice installs the Eclair app on her mobile device.
+Alice notices a few different elements on this page, that help her ascertain that this is, most likely, the correct "Eclair Mobile" wallet she is looking for. Firstly, the organization "ACINQ" footnote:[ACINQ: Developers of the Eclair Mobile Lightning wallet (https://acinq.co/).] is listed as the developer of this mobile wallet, which Alice knows from her research is the correct developer. Secondly, the wallet has been installed "10,000+" times and has more than 320 positive reviews. It is unlikely this is a rogue app that has snuck into the Play Store. Satisfied by these findings, Alice installs the Eclair app on her mobile device.
 
 [WARNING]
 ====

ch03.asciidoc

@@ -357,7 +357,7 @@ While Lightning could have been designed to share balance information of channel
 
 Payments on the Lightning Network are forwarded a long a path of channels from one participant to another one.
 Thus a path of payment channels has to be selected.
-If we would know the exact channel balances of every channel we could easily compute one of the standard path finding algorithms from computer science to choose a path.
+If we knew the exact channel balances of every channel we would easily be able to compute one of the standard path finding algorithms taught in any computer science program to choose a path for the payment.
 This could even be down in a way to optimize the fees that would have to be paid by the payer to the nodes that kindly foward the payment.
 However as discussed the balance information of all channels is and cannot be available to all participants of the network.
 Thus we need to have some path finding strategy.
@@ -365,29 +365,38 @@ This strategy relates closely to the routing algorithm hat is used.
 As we will see in the next section on the Lightning Network we use a source based onion routing protocol for routing payments.
 This means in particular that the sender of the payment has to find a path through the network.
 As mentioned before with only partial information about the network topology this is a real challange and active research is still being conducted into optimizing this part of the Lightning Network implementations.
-The fact that the pathfinding problem is not fully solved for the case of the Lightning Network is a major point of criticism towards the technology.
-On the good side we emphasize that the certainly not optimal strategy - that is currently being used - of probing paths until one has enough liquidity to forward the payment works still rather well.
+The fact that the pathfinding problem is not fully solved for the case of the Lightning Network is a major point of criticism towards the technology. 
+On the good side we emphasize that the certainly not optimal strategy - that is currently being used - of probing paths until one has enough liquidity to forward the payment works still rather well. 
+Also it is worthwhile to note that this probing is done by the LN node or wallet and is not directly seen by the user of the software. 
+The user might only realize that probing is taking place if the payment is not going though instantly as it usually would.
 
 [NOTE]
 ====
 On the Internet we use the internet protocol and the IP forwading 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.
-While the routing protocol that is used for data and infrmation transport on the internet has the really nice property of allowing the internet hosts to collaboratively finding a path for the information through the internet we cannot reuse and adopt this protocol for forwarding payments on the Lightnin network.
+While the routing protocol together with the border gateway protocol which are used for data and infrmation transport on the internet have the really nice property of allowing the internet hosts to collaboratively finding a path for the information through the internet we cannot reuse and adopt this protocol for forwarding payments on the Lightninh network.
 ====
 
-
-
-* trivial case / channel partner as destination with enough funds in the channel
-* topology information from the gossip protocol
-* fees and pathfinding from destination to source
+Of course path finding is trivial if we want to pay our direct channel partner and we have enough balance on our side of the channel to do so. 
+In all other cases information from the gossip protocol is used to help with path finding. 
+This includes which public payment channels are connecting nodes, which capacity the channels have and what fee policies the owners require. 
 
 ==== Onion routing
 
-* construct an onion using
-** SPHINX
-** payment hash
-** path
+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.
+
+1. The most important property is that a routing node can only see on which channels it received an onion and on which channel to set up an HTLCs and thus to which peer to forward the onion. This means that no routing node can know who initiated the payment and for whom the payment is supposed to be. The exception of course would be if the node is the recipient. In that case it would know that it was the final destination. 
+2. The onions are small enough to fit into a single TCP/IP package and actually even a link layer frame this will make traffic analysis for intruding the privacy of the payments almost impossible
+3. The Onions are constructed in a way that they will always have the same length independent of the position of the processing node along the path. 
+4. Onions can have up to 20 hops included allowing for sufficient long paths. 
+5. The encryption of the onion for every hope uses different ephemeral encryption keys with every single onion. Should a key (in particular the private key of the public node key) leak at some point in time an attacker who collected onions cannot decrypt the other onions that have been stored. 
+6. Errors can be send back from the erring node in an encrypted way to the original sender. This is particular useful as we have seen that Lightning nodes who initiate the Onions select a path without knowing weather every node has enough liquidity along their channels to forward the payment. 
+
+As mentioned we will discuss the details of the Onion Format later but we note already that the `Payment Hash` while needed to set up the HTLCs for the payment is not transported within the onions. 
+The `Payment Hash` is rather included to the Lightning Message that also transports the onion.
 
 ==== Payment Forwarding Algorithm
 
@@ -397,8 +406,14 @@ While the routing protocol that is used for data and infrmation transport on the
 * sending back errors
 
 === Missing bits
-* Noise_XK
-* Lightning Messages
+From a computer science perspective the Lightning Network protocol is mainly a peer to peer protocol between its participants. 
+All communication between participants is send via so called Lightning Messages. 
+Most importantnly communication is needed to open and close payment channels, to send and receive onions, to set up and settle or fail htlcs and for exchanging gossip information. 
+The Lightning messages are send in an encrypted way after a peer connection has been established. 
+Establishing the peer connection follows a cryptographic handshake following the Noise Protocol Framework. 
+The Noise Protocol Framework is a collection of templates for cryptographic handshakes and is also used by WhatsApp and Wireguard. 
+Using the Noise Protocol Framework makes sure that every message that is send via Lightning is encrypted and authenticated.
+This makes development a little bit tricky as one cannot easily monitore ones own traffic on a tool like wireshark for debugging. footnote:[Luckily tools exist to make developers live easier: https://github.com/nayutaco/lightning-dissector]
 
 === some thoughts that where supposed to be at other places but didn't make it to the text yet
 * network of payment channels

glossary.asciidoc

@@ -347,12 +347,13 @@ Proof-of-Work::
     A piece of data that requires significant computation to find. In Bitcoin, miners must find a numeric solution to the SHA256 algorithm that meets a network-wide target, the difficulty target.
 
 Relative Timelock::
-    TBD.
+    Relative Timelock is a kind of timelock that allows an input to specify the earliest time it can be added to a block based on how long ago (which is relative) the output refered by that input was included in a block. Such a feature is jointly achieved by nSequence field and CheckSequenceVerify opcode, which are introduced by BIP68/112/113. 
 
 Revocable Sequence Maturity Contract::
     This contract is used to construct a payment channel between two Bitcoin or Lightning Network users who do not need to trust each other.
     The name comes from a sequence of states which are encoded as commitment transactions and can be revoked if wrongfully published and mined by the Bitcoin network.
     These contracts are commonly referred to as RSMCs.
+    Unlike a HTLC, whose timeout is to make a HTLC temporary, and therefore should be absolute; a RSMC timeout is meant to only start when a commitment transaction is mined, and therefore should be using a Relative Timelock.
 
 Revocation Key::
     Each Revocable Sequence Maturity Contract contains two revocation keys.