Lightning Network Basics — Part 5
I will present the basic technical details of the Lightning Network over the course of several articles.
In this article, Lightning amount transfer is explained. In BOLT #2, it is called Normal Operation.
Transfers on the Lightning Network are off-chain, that is, real-time settlement is achieved by not exposing transactions to the Bitcoin blockchain. However, there is a possibility that malicious operations can be performed because it is not published on the blockchain.
Even so, we update the Commitment Transaction that can be disclosed so that the transfer can be done without the trust of the other party while remaining off-chain, and we are careful not to disclose the old Commitment Transaction before the balance is updated.
Overview
Lightning Network transfers can be relayed between channels. Whether or not it is relayed, it is up to the source node to decide which route to forward. Therefore, the data to be transferred contains the information of the transfer amount and the transfer route.
And the relay node can take a commission. The source node creates a forwarding route while taking into account the commission received by the relay node. It seems that the fee is paid by the sending node, so it seems that an algorithm that minimizes it as much as possible is adopted.
Confidentiality is also considered. Even if Alice pays Bob, the receiving Bob only knows the final amount received and the channel it was sent to, but does not know the route up to that point.
Similarly, relaying nodes know which channel they received and which channel to forward next, but they do not know which node started forwarding and which node received it last.
invoice
The operation varies depending on the user interface, but as a Lightning Network protocol, it starts with the transfer destination node creating invoice data.
The main data required for the invoice are:
- final received amount
- Payment Hash from final received node created PreImage
- ID of the final LN node to receive
The invoice format is specified in BOLT #11 , but invoices are not exchanged using the Lightning Network protocol. You don’t need to conform to the BOLT #11 format if you have enough information to start transferring.
Onion Routed Packet
All transfer routes are determined by the transfer source node, and relay nodes transfer according to instructions.
Even if the relay node receives the transfer route data, it is anonymized so that the receiving node only knows which channel to transfer to next.
For example, if the route is A→B→C→D, A creates a route B→C→D.
Then, for B, route information to transfer to C, for C, route information to transfer to D, and for D, there is no need to transfer to the next (i.e., D is the final transfer destination) Encode the information so that only each node can decode it. Also, encoding is performed in order from the final transfer destination to the transfer source, and the method of decoding this data is similar to peeling off the skin of an onion one by one, so ONION routing etc. Details are in BOLT #4 .
Transfer start (add HTLC)
The transfer start node that receives the invoice data performs calculations to start the transfer. Here is an example of using one channel to initiate the transfer ( not Multi Part Payment ).
- Receive invoice data from the final destination node.
- Create forwarding routes. If you don’t have a channel, or if you do have one but can’t find a channel that reaches the final destination node, you can’t start the transfer.
- If there is a route, calculate whether or not the amount can be transferred by that route. If you relay, you pay a fee, so consider that as well and determine whether the channel will start transferring the amount you need to pay. If you can’t pay with the first discovered route, create another route. If a route from the transfer source to the transfer destination can be created, the process is complete.
- Mask each destination channel with Onion Routed Packet.
update_add_htlcInitiate a transfer using a message. In addition to the Onion Routed Packet, we also send the Payment Hash listed in the invoice data.
If the transfer cannot continue
update_add_htlcIf the route indicated by the message is incomplete and the transfer cannot be continued, a message to cancel the addition of HTLC is sent to cancel the HTLC.
The behavior after HTLC cancellation to the transfer start node is up to the implementation of the node, but normally it will search for another route other than the route where the transfer was interrupted and start the transfer again. If the transfer fails anyway using the channel information that the transfer start node has, it will end up with an error like “route not found”.
There are many reasons why a transfer cannot continue.
- Destination node is not running
- channel is closed
- Insufficient balance to transfer on channel
- Route creation is not possible due to old or insufficient channel data in the transfer source node
Fulfill HTLC
After update_add_htlc message succeed, adds an HTLC to each Commitment Transaction. Once the process to the final forwarding node is complete, the HTLC is resolved and the channel is returned to channel balance.
- The final destination node sends the
update_fulfill_htlcmessage with PreImage. - The receiving node will reflect the HTLC in the channel balance once it has verified that the PreImage is the source data for the Payment Hash it sent in the
update_add_htlcmessage. - If it is a node that has received an update_add_htlc message, it sends an
update_fulfill_htlcmessage to that channel. - Repeat this operation, and when the HTLC of the source node is resolved, the transfer is complete.
If update_fulfill_htlc doesn’t resolve HTLC
If the final destination node did not deploy the PreImage, it closes the channel and resolves the HTLC with a timeout on-chain.
If the destination node deploys PreImage by exposing a Commitment Transaction, close the channel and resolve the HTLC by PreImage on-chain.
In conclusion
This article introduced Lightning amount transfer(BOLT#2 Normal Operation).
