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

routing: chapter edits towards tail end

Browse Source
This commit is contained in:
Olaoluwa Osuntokun 2020-11-17 18:36:55 -08:00
parent 68e8d2fbb3
commit 030829e2b1
No known key found for this signature in database
GPG Key ID: 3BBD59E99B280306
1 changed files with 15 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
routing.asciidoc
View File

@ -547,22 +547,23 @@ In the network today, Alice learns about the public key via the gossip network,
In the first part of the routing chapter you have learnt that payments securely flow through the network via a path of HTLCs.
You saw how a single HTLC is negotiated between two peer and added to the commitment transaction of each peer.
In the second part you have seen how the necessary information for setting up HTLCs along a path of hops are being transfered via onions from the source to the sender.
A mechanism that protects the privacy of payer and payee.
However there are quite some challenges and things that can go not as expected.
This is why we we want to discuss how errors are being handled and what users and developers should take into consideration.
In the second part you have seen how the necessary information for setting up HTLCs along a path of hops are being transferred via onion packets from the source to the sender.
However, in the above scenarios, we only discussed flows where everything goes as expected (the optimistic path).
In this section, we'll now turn out attention into the various scenarios where the payment flow across the route breaks down.
Most importantly it is absolutely necessary that you understand that once your node sent out an onion on your behalf (most likely because you wanted to pay someone) Everything that happens to the onion is now out of your control.
First, it's important to know that once a node sends a fully valid onion packet out to the first hop, they cannot directly influence the course of the route.
In other words:
* You cannot force nodes to forward the onion immediately.
* You cannot force nodes to send back an error if they cannot forward the onion because of missing liquidity or other reasons.
* You cannot be sure that the recipient has the preimage to the payment hash or releases it as soon as the HTLCs of the correct amount arrived.
By setting up an HTLC - which you do by sending out an onion - you have committed to settle the HTLCs in exchange for the preimage if the preimage arrives before the absolute timelock of the HTLC.
This can be very frustrating from a use experience point of view.
When sending out an HTLC and its corresponding onion packet, you as the sender must be prepared to wait the worst-case CTLV timelock period before funds are returned back to the sender (if the route fails).
This explicit, awareness of the worst-case delay when sending a payment may be difficult to explain properly from a user experience perspective for end user wallets.
You want to quickly pay a person but the payment path that your node choose has CLTV deltas that quickly add up to several 100 blocks which is a couple of days.
This means now that if nodes on the path misbehave - on purpose or maybe just because they have a downtime which your node didn't know about - you will have to wait even though you don't see a preimage.
You must not send out another onion along a different path because there is a risk that both payments will settle eventually.
You must not send out another onion along a different path which uses the same payment hash because there is a risk that both payments will settle eventually.
While our user experience is that most payments find a path and settle in far less than 10 seconds the Lightning Network protocol cannot and does not give any service level agreement that within this time payments will settle or fail.
[NOTE]
@ -571,7 +572,7 @@ There are ideas out that might solve this issue to some degree by allowing the p
====
Despite these principle problems there are plausible situations in which the routing process fails and in which honest nodes can and should react.
This is why the onion protocol has the ability to send back errors.
This is why the onion protocol has the ability to send back errors in a fail-fast manner that allows nodes to remove the HTLC *off chain*, without needing to close out channels.
Some - but not all - of the reasons for errors could be:
* A node has not enough liquidity to set up the next HTLC
@ -581,10 +582,10 @@ Some - but not all - of the reasons for errors could be:
* The recipient might not have issued an invoice and does not know the payment details.
* The amount of the final HTLC is too low and the recipient does not want to release the preimage.
If errors like those occur a node should send back a reply onion.
If any of the above errors are encountered, a node will send back an encrypted error reply onion back the sender.
The reply onion will be encrypted at each hop with the same shared secrets that have been used to construct the onion or decrypt a layer.
These shared keys are all known to the originator of the payment.
The onion innermost onion contains the error message and an HMAC for the error message.
The innermost onion contains the error message and an HMAC for the error message.
The process makes sure that the sender of the onion and recipient of the reply can be sure that the error really originated from the node that the error messages says.
Another important step in the process of handling errors is to abort the routing process.
We discussed that the sender of a payment cannot just remove the HTLC on the channel along which the sender sent the payment.
@ -595,8 +596,7 @@ Thus Bob would never agree to remove the HTLC with Alice unless he already has r
If however the HTLC between Alice and Bob are set up and the HTLC between Bob and Wei are set up but Wei encounters problems with forwarding the onion it is perfectly Wei has more options than Alice.
While sending back the error Onion to Bob Wei could ask him to remove the HTLC.
Bob has no risk in removing the HTLC with Wei and Wei also has no risk as there is no downstream HTLC.
Removing an HTLC is happening very similar to adding HTLCs.
Due to the just presented argument only peers who have accepted an offered HTLC can initiate the removal of HTLCs.
Removing an HTLC is the reverse of adding one in the first place from the PoV the commitment transaction.
In the case of errors peers signals that they wish to remove the HTLC by sending an `update_fail_htlc` or `update_fail_malformed_htlc` message.
These messages contain the id of an HTLC that should be removed in the next version of the commit transaction.
In the same handshake like process that was used to exchange `commitment_signed` and `revoke_and_ack` messages the new state and thus pair of commitment signatures has to be negotiated and agreed upon.
@ -610,9 +610,9 @@ You have learnt how HTLCs are removed if there is an error.
Of course HTLCs also need to be removed and the balance needs to be updated if the chain of HTLCs was successfully set up to the destination and the preimage is being released.
Not surprisingly this process is initiated with anther lightning message called `update_fulfill_htlc`.
You will remember that HTLCs are set up and supposed to be removed with a new balance for the recipient in exchange for a secret `preimage`.
Recalling the complex protocol with `commitment_signed` and `revoke_and_ack` messages you might wonder how to make this exchange `preimage` for new state atomic.
Recalling the full-duplex protocol with `commitment_signed` and `revoke_and_ack` messages you might wonder how to make this exchange `preimage` for new state atomic.
The cool thing is it doesn't have to be.
Once a channel partner with an accepted incoming HTLC knows the preimage can savely just pass it to the channel partner.
Once a channel partner with an accepted incoming HTLC knows the preimage can safely just pass it to the channel partner.
That is why the `update_fulfill_htlc` message contains only the `channel_id` the `id` of the HTLC and the `preimage`.
You might wonder that channel partner could now refuse to sign a new channel state by sending `commitment_siged` and `revoke_and_ack` messages.
This is not a problem though.
@ -631,7 +631,6 @@ Thus there are two small economic risks involved with the participation in the r
. Higher onchain fees in case of forced channel closes due to the higher footprint of HTLCs
. Opportunity costs of locked funds. While the HTLC is active the funds cannot be used otherwise.
In economics and financial mathematics the idea to pay another person that takes a risk is widely spread and seems reasonable.
Owners of routing nodes might want to monitor the routing behavior and opportunities and compare them to the onchain costs and the opportunity costs in order to compute their own routing fees that they wish to charge to accept and forward HTLCs.
Also one should notice that HTLCs are outputs in the commitment transaction.