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

Edits to payment forwarding and message encryption

Browse Source
This commit is contained in:
Andreas M. Antonopoulos 2020-07-20 09:54:22 -04:00
parent 294bc50579
commit 49acae8574
1 changed files with 27 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
03_how_ln_works.asciidoc
View File

@ -255,7 +255,6 @@ While a private channel will not be known to others while it is in use, it's exi
Private channels are still used to route payments but only by the nodes which are aware of their existence, or given "routing hints" about a path that includes a private channel.
When a channel and its capacity is publicly announced using the gossip protocol, the announcement can also include information about the channel (metadata), such as it's routing fees and timelock duration.
When new nodes join the Lightning Network they collect the channel announcements propagated via the gossip protocol from their peers, building an internal "map" of the Lightning Network. This map can then be used to find paths for payments, connecting channels together end-to-end.
@ -528,64 +527,43 @@ Onion routing will be examined in detail in <<onion_routing>>.
==== Payment Forwarding Algorithm
In stark contrast to the Internet Protocol Forwarding Algorithm on the Lightning Network it is only the sender of a payment that decides the path it takes to the recipient.
Forwarding nodes can only reject a path.
This can happen either on purpose or because they are not able to fulfill the request.
The payment forwarding algorithm is initiated by the sender of a payment who selects a path through the Lightning Network and constructs an onion.
It contains information about the payment for the recipient, routing hints for the intermediary nodes.
Routing fees which those nodes will earn if (and only if) the payment is successfully delivered and settles with the release of the `Payment Hash` are also included to the onion.
Once the sender of payment finds a possible path across the network and constructs an onion, the payment is forwarded by each node in the path, processing one layer of the onion at each hop.
All Lightning Nodes must follow the payment forwarding algorithm.
Upon receiving a Lightning Message called `update_add_htlc` which contains the `Payment Hash` and the onion package it needs to follow through X steps:
Each intermediary node receives a Lightning Message called `update_add_htlc` with a payment hash and an onion. The intermediary node executes a series of steps, called the _payment forwarding algorithm_:
1. It needs to decrypt the outer layer of the onion and use the HMAC to make sure that the onion was not corrupted.
2. It will check that it can fulfill the routing hints in the way that the fees are respecting its fee announcements and that it has enough liquidity on the outgoing channel or is even owner of the specified channel.
3. It needs to work with its peer on the incoming channel to update the channel state to include the offered HTLC.
4. It will have to add some padding data to the end of the onion to keep it as a constant size even though it removed some data from the beginning.
5. It will then follow the routing hints from its layer of the onion to forward the modified onion package on its outgoing payment channel by also sending and `update_add_htlc` message which includes the same `Payment Hash` and the onion.
6. Obviously it also has to collaborate with its peer on the outgoing channel to move forward the state to also include the offered `HTLC`.
1. The node decrypts the outer layer of the onion and checks the message's integrity.
Of course those steps will be interrupted and aborted if an error is detected.
In most of those cases an error message will be send back to the originator of the received `update_add_htlc` message.
If for example in the first step the node detects that the onion was corrupted it will not proceed to the second and subsequent steps to move forward the channel state on the receiving channel to include the HTLC.
Similarly if in the second step the node discovers that it won't be able to fulfill the routing request or that not enough fees have been included it will also abort the payment forwarding algorithm and rather send back an error.
2. It confirms that it can fulfill the routing hints, based on the channel fees and available capacity on the outgoing channel.
We note that the error is also an onion reply package.
Even though the node sending the error does not know who initially sent out the payment the error message will be encrypted with the key that was used to encrypt the forwarding nodes layer.
The reply onion is then sent back on the incoming channel.
The node on the other side knows on which channel it received an onion and with which other channel it has an HTLC with the same `Payment Hash`.
Thus the error can safely propagate back towards the originator.
Nodes that are sending back an error Onion must on their way remove the HTLCs from their payment channels to make sure that they cannot be enforced.
3. It works with its channel partner on the incoming channel to update the channel state.
[Note]
====
It is important to understand that HTLCs have a time measured in absolute blockheight through which they are valid.
Once the sender of a payment sends away the onion it is completely out if their control what happens.
Honest nodes SHOULD either forward the onion as quickly as possible or send an error back the original.
While sender expects nodes along the path to be honest it has according to the protocol no power of making sure that nodes act quickly.
4. It adds some padding to the end of the onion to keep it at a constant length since it removed some data from the beginning.
5. It follows the routing hints to forward the modified onion package on its outgoing payment channel by also sending an `update_add_htlc` message which includes the same payement hash and the onion.
Thus payments can currently get stuck if nodes want to behave maliciously.
While the likelihood for a payment to fail is pretty high if it does not settle quickly a node SHOULD never initiate another payment attempt along a different path before the onion returned with an error as a node might just have delayed the forwarding of the payment.
Nodes which act maliciously by delaying the forwarding of payments or errors are actually hard to detect due to the privacy properties that are gained with the onion routing scheme.
6. It works with its channel partner on the outgoing channel, to update the channel state.
Of course, these steps are interrupted and aborted if an error is detected and an error message is sent back to the originator of the `update_add_htlc` message. The error message is also formatted as an onion and sent backwards on the incoming channel.
=== Missing bits
From a computer science perspective the Lightning Network protocol is mainly a peer to peer protocol between its participants.
All communication between participants is sent via so called Lightning Messages.
Most importantly 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 sent 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 sent via Lightning is encrypted and authenticated.
This makes development a little bit tricky as one cannot easily monitor one's own traffic on a tool like wireshark for debugging. footnote:[Luckily tools exist to make developer's lives easier: https://github.com/nayutaco/lightning-dissector]
As the error propagates backwards, each node removes the pending payment from their incoming and outgoing channels, rolling back the payment in the opposite way from which it started.
=== some thoughts that were supposed to be at other places but didn't make it to the text yet
* network of payment channels
* different scope of the network
** global path finding (entire knowledge of the network necessary)
** multihop routing (onion necessary only a subset of nodes involved)
** locally setting up and settling HTLCs (only peers involved)
While the likelihood for a payment failure is high if it does not settle quickly, a node should never initiate another payment attempt along a different path before the onion returns with an error.
=== Peer-to-Peer Communication Encryption
The Lightning Network protocol is mainly a peer-to-peer protocol between its participants. As we saw in previous sections, there are two overlapping functions in the network, forming two logical networks that together are _The Lightning Network_:
1. A broad peer-to-peer network that uses a gossip protocol to propagate topology information, where peers randomly connect to each other. Peers don't necessarily have payment channels between them, so they are not always channel partners.
2. A network of payment channels between channel partners. Channel partners also gossip about topology, meaning they are peer nodes in the gossip protocol.
All communication between peers is sent via messages called _Lightning Messages_. These messages are all encrypted, using a cryptographic communications framework called the _Noise Protocol Framework_. The Noise Protocol Framework allows the construction of cryptographic communication protocols that offer authentication, encryption, forward secrecy and identity privacy. The Noise Protocol Framework is also used in a number of popular end-to-end encrypted communications systems such as WhatsApp, Wireguard, and I2P. More information can be found here:
https://noiseprotocol.org/
The use of the Noise Protocol Framework in the Lightning Network ensures that every message on the network is both authenticated and encrypted, increasing the privacy of the network and its resistance to traffic analysis, deep packet inspection and eavesdropping. However, as a side-effect, this makes protocol development and testing a bit tricky as one can't simply observe the network with a packet capture or network analysis tool such as wireshark. Instead, developers have to use specialized plugins that decrypt the protocol from the perspective of one node, such as the _lightning dissector_, a wireshark plugin:
https://github.com/nayutaco/lightning-dissector
=== Thoughts about Trust
As long as a person follows the protocol and has their node secured, there is no major risk of losing funds when participating in the Lightning Network.