Lightning network in depth, part 2: HTLC and payment routing

Published in

Softblocks

12 min readMar 9, 2018

In the previous article, we analysed in detail the functioning of payment channels and several methods to secure the payments passing through these channels. However, it is not enough to build a functioning network of channels: even if we are sure that inside every channel everyone is playing fair, we cannot guarantee the delivery of funds by a chain passing through a number of channels. That is where the smart contracts known as HTLC (hash-timelock-contracts) come in. In this article, we discuss the way they work and use an example to show how a payment is accomplished in the Lightning network.

HTLC
Lightning network example
Clearing out failures
Transport protocol
Benefits and use cases
Conclusion
Links

Hash time lock contracts (HTLC)

The structure of the HTLC contracts is not complicated but very efficient, enabling to create payments with a certain ‘expiration date’. As you have probably already conjectured, a HTLC contract consists of two parts: hash verification and time expiration verification.

Let us start with the hash. To create a HTLC payment, the secret R should be created at first, and then its hash should be calculated. Any figure, any word can serve as the secret: in any case, it is nothing else than a byte combination.

H = Hash(R)

This hash H will be included in the locking script. Therefore, only the person who knows the secret that was hashed to get H will be able to use the payment. The secret R is also known as preimage.

The second part of the HTLC contract is the verification of the expiration time of the payment. If the secret was not revealed in time and the payment was not used, the sender can retrieve all the funds.

Let us consider an example of an HLTC payment destined to a certain person:

# check if secret R is preimage of H
HASH160 <H> EQUAL
IF
    # check if person, who revealed secret is intended payee
    <Payee Public key> CHECKSIG
ELSE
    # check if time-lock is ended
    <locktime> CHECKLOCKTIMEVERIFY
    # check that person that requested refund is original payer
    <Payer Public Key> CHECKSIG
ENDIF

If the true secret R, the preimage of the H hash, is presented, we get into the IF flow and undergo a verification aiming to know if the person who found the secret R is the intended recipient of the payment. To spend this payment, the recipient should present a quite simple unlocking script:

<sig> <secret R>

If the proposed secret R is false, we get into the ELSE flow where it is first verified whether the allocated time has passed. If yes, the sender can retrieve all the funds. The unlocking script for the retrieval of funds is the same, the only difference being a need to intentionally present a wrong secret in order to get into the ELSE flow:

<sig> <wrong secret>

Of course, it is but a very basic implementation of a HTLC contract, representing an ordinary time-lock payment. You can add any number of different conditions to the script: by removing, for instance, the verification of the public key in the IF flow, we can make the payment accessible to everybody who knows the secret; we can also, imitating multisig, ask for several signatures instead of one, etc.

P. S. In this case, we employed the opcode CHECKLOCKTIMEVERIFY, using the absolute value to define the timelock, for instance: “This output cannot be spent before the block #546212.” Within the Lightning Network, there is another opcode, a more ‘flexible’ one, which is also used: CHECKSEQUENCEVERIFY, using the relative values for the timelock, for instance: “This output cannot be spent until 1000 blocks since the moment when the transaction was broadcasted into the network.”

Lightning Network Example

Now, when we finally have analysed all the components, we can consider the entire picture of how does the Lightning Network function. This example of ours will have five participants: Alice, Bob, Carol, Diana and Eric. Every one of them has open payment channels with others with the balance of 2 bitcoins on every side of every channel. So, having a chain of channels, let us try to execute the payment from Alice to Eric.

A series of bidirectional payment channels linked to form a Lightning Network that can route a payment from Alice to Eric

Let us assume that Alice wants to transfer 1 bitcoin to Eric. However, as we see, they are not connected by a direct channel, and opening a new channel requires time and money. Luckily, Alice is connected to the Lightning Network and can make an indirect payment with the help of a series of HTLC contracts. Let us examine this payment step by step.

Step-by-step payment routing through a Lightning Network

Eric creates a secret R and communicates its hash to Alice (he does not show the secret itself to anyone).
Alice uses this hash to create a HTLC with a timelock set on 10 blocks forward, for the amount of 1.003 BTC. The additional 0.003 BTC will be used as a fee to the intermediate participants for their participation in the chain. So, Alice locks her balance of 1.003 BTC in the HTLC, using the following rule: “Alice will pay Bob 1.003 BTC if he find the secret R during the next 10 blocks, otherwise the funds will return to Alice.” The balance of the channel was changed by a commitment transaction and is now as follows: Bob has 2 BTC, Alice has 0.997 BTC, and 1.003 BTC are locked in the HTLC.
In his turn, Bob, having at his disposal the Alice’s commitment transaction (the HTLC sent to the channel that connects them), creates a HTLC on the channel that connects him to Carol for the amount of 1.002 BTC with a timelock set on 9 blocks forward. He uses the same hash as Alice. Bob knows that Carol will have to find out the secret R to unblock the HTLC sent by him, and as soon as she does it, he will also learn it and will therefore be capable to unlock the 1.003 BTC sent to him by Alice. If Carol cannot find out the secret R, Bob and Alice will simply retrieve their funds on the expiration of the timelock. Let us also remark that the amount of funds sent by Bob is 0.001 BTC smaller than the funds he receives: it is a fee he took for his participation in the chain. The balance of the channel between Bob and Carol is as following: Carol has 2 BTC, Bob has 0.998 BTC, and 1.002 BTC are locked in the HTLC.
Carol, having received Bob’s commitment transaction, creates an HTLC (using the hash that Bob used) on the channel with Diana for the amount of 1.001 BTC with a timelock set on 8 blocks forward. If Diana can discover the secret R before the 8 blocks are over and unblock the HTLC to get 1.001 BTC, Carol will also learn the secret and will therefore be able to unblock the 1.002 BTC sent to her by Bob, therefore earning 0.001 BTC. The balance of the channel between Carol and Diana is now as following: Diana has 2 BTC, Carol has 0.999 BTC, and 1.001 BTC are locked in the HTLC.
Finally, Diana sends a HTLC (always using the same hash) to her channel with Eric for the amount of 1 BTC and a timelock set on 7 blocks forward. The balance of the channel between Diana and Eric is now as following: Eric has 2 BTC, Diana has 1 BTC, and 1 BTC are locked in the HTLC.
Now, we have arrived to the end of our chain. Eric, having the secret R, whose hash was used in all the HTLC commitment transactions, can unlock the HTLC sent to him by Diana and obtain 1 BTC. As soon as Eric uses the secret to receive the funds, it becomes available to Diana as well. The balance of the channel between Diana and Eric is now as following: Eric has 3 BTC and Diana has 1 BTC.
Diana, having received the secret, unblocks 1.001 BTC sent by Carol and, by doing so, reveals her the secret. The balance of their channel is now as following: Diana has 3.001 BTC and Carol has 0.999 BTC.
Carol, having received the secret, unlocks 1.002 BTC sent by Bob and, by doing so, reveals him the secret. The balance of their channel is now as following: Carol has 3.002 BTC and Bob has 0.998.
Finally, Bob uses the secret to obtain 1.003 BTC from the channel between him and Alice. The balance of their channel is now as following: Bob has 3.003 BTC and Alice has 0.997.

In this way, Alice paid Eric 1 BTC without opening a new channel that would link them directly. No one of the chain participants was obliged to trust others, and they earned 0.001 BTC as a fee for their role as middlemen. In the case of anybody from the chain failing to perform their part of work, nobody would have lost the money that would simply stay frozen until the expiration of the timelock.

Clearing out failures

In our example, everything went smoothly but in real life everything would obey Murphy’s law, and if something can go wrong, it would go wrong, so let us examine the ‘protection’ mechanisms of the Lightning Network.

Evidently, the longer the chain used to deliver the funds, the higher the probability that they would not reach the end: some of the participants may close the channel and another one may simply lose the Internet connection. Let us examine two possibilities of something going wrong.

Broken channel

In the first case, let us imagine that the funds have successfully reached the end of the chain, but on the way back (when the secret should escalade the chain, reaching the very beginning) a problem has emerged when one participant refused or was unable to cooperate. In our example, it would be Bob.

Failure in funds delivery due to one of the channels closing,

Diana, when the chain has reached her, immediately retrieves her funds, using the secret and revealing it to Carol. Carol also wishes to get her money back from Bob but he does not respond so, to avoid risk, she closes the channel, sending the last commitment transaction (the HTLC contract previously sent by Bob) into the blockchain and, with the help of the secret, retrieves the funds. In this case, Bob still has three days to surface and took his money from Alice (as the transaction has made it to the blockchain, he can easily find it and see the R). Otherwise, at the expiration of the timelock, she will be able to retrieve all her money.

It can be seen that if a participant for some reason leaves the system, he or she is the only one who risks losing funds, while all other participants of the chain are safe.

Rerouting

In our second case, let us examine a situation in which the funds did not reach the end of the chain, again because of a problem with one of the participants. Now it would be Carol.

The first and the most obvious way is simply to wait until the expiration time of the HTLC contracts to be able to retrieve the funds and send a new payment.

One of nodes in payment route is unresponsive.

But what should they do if Alice is in a hurry? Of course, it is possible to send a new payment by another chain without waiting for the return of the funds, but what if Carol comes back, connects with Bob and finishes the chain? In this case, Alice would end sending the double amount of money.

So should we always, in the case of failure, wait until the expiration time to send a new payment? Fortunately, to avoid waiting for the timelock to expire, we may ‘cancel the previous payment. To do this, Diana (the recipient) should send an equivalent amount of money to Alice, using the same hash as when sending it for the first time, and the chain can be different. Now, if Carol comes back and finishes her part of the work, the money will simply go around the circle. It means that the failed payment can be considered null and void and another payment can be sent by another chain.

Alice “cancelled” old payment and now can send new one without any risk/

Payment amount

You might have remarked that while Alice ‘cancelled’ the first payment and can now send a new one, it does not change the fact that the funds are frozen and she might have not enough money to repeat the operation. This is why, when using the Lightning Network, it is preferable to use HTLC to send smaller sums. As commitment transactions do not hit the blockchain, the amount can be divided in really small parts. It means that whenever a chain stops operating, only a small part of the payment stays frozen, the one that was sent the last.

Transport protocol

Another very important feature of the Lightning Network should be mentioned: the entire information about the chain is completely anonymous. It means that every participant of the chain knows only about his or her ‘section’: for instance, for Carol the payment looks like a transfer of funds from Bob to Diana, she does not know that Bob got the money from Alice or that Diana will transfer it to Eric.

Lightning uses the Sphinx multiple encryption protocol. When using Lightning, Alice wraps every section of the network in a layer of encryption, starting from the end of the chain. She encrypts a message for Eric, using his public key. This message is included in the message for Diana that will be encrypted with her own key, in turn, and the message for Diana will be included in the message for Carol, also encrypted with her key and so on until the beginning of the chain. In this way, Bob would only be able to decrypt only the superior layer of the message, destined for him, and he would send the message further to Carol etc. At every stage, only the necessary information is revealed: the amount of money to be sent, the size of the commission fee, the timelock etc.

To make it impossible to guess the length of the chain by the weight of the message, it has a fixed size, as if twenty persons participated in the network. Every participant, excluding the last one, sees the images of the same size and believes that there are twenty more participants.

Benefits and use cases

Of course, the benefits of the Lightning Network do not boil down to the bitcoin scalability as many people think. Let us consider certain possibilities that we have thanks to Lightning.

Instant transactions. When using Lightning, the transactions are almost instantaneous. It becomes possible to pay for your coffee with bitcoin.
Exchange Arbitrage. At present, a quick transfer of funds from one exchange to another does not seem possible because 3 to 6 blocks are needed to confirm the transaction. If the exchanges start using Lightning, the users will be able to transfer the funds instantly, allowing for arbitration transactions. The exchanges will also stop needing ‘cold’ wallets to store funds, greatly decreasing the danger of theft.
Micropayments. The commission fee in bitcoin is too high for micropayments. Hard to imagine somebody ready to pay 0.001 BTC to transfer the same or smaller amount of money. With Lightning, you will have a possibility to instantly transfer any amounts of money so that, for instance, you will be able to pay your Internet by megabyte.
Financial smart contracts and transactions. Financial contracts are extremely time-sensitive and often require a lot of calculations. By moving their majority ‘outside’, we get an opportunity to create very complicated transactions and contracts without recording them in the blockchain.
Cross-chain payments. If there are similar hash functions in the blockchains with different consensus rules, it is possible to make transactions between them. In this case, the participants will have no need to trust each other or to use middlemen.
Privacy. In Lightning, transactions are much more anonymous than in the bitcoin blockchain because the participants of the chains used to make a payment cannot see the sender or the recipient.

Conclusion

We have now completed our analyse of the Lightning Network. In our next articles, we will tell you how it is possible to use the HTLC contracts to enact a cross-chain atomic swap between the bitcoin and the litecoin.