<p>One reason to use HTLCs for single-hop payments in the Lightning Network would be to make them <em>indistinguishable</em> from multi-hop payments to the receiver. This way, the receiver does not know whether it was their direct peer who initiated the payment, or whether they are merely forwarding the payment on for somebody else. Since they look identical to the receiver, the receiver must assume that some other node, who they know nothing about, initiated it.</p>
<p>The way in which HTLCs are created is also useful even for the single-hop use case, because they extend the RSMC model with <em>conditional</em> payments. With RSMCs alone, if Alice wishes to pay Bob, she creates a new commitment transaction by reducing the channel balance paid to her, and increasing the balance paid to Bob via the RSMC output. This transaction is then signed by Alice. Assuming that nobody misbehaves, Alice has effectively <em>already paid</em> Bob. There is no way this payment can be undone by Alice - for example, if Bob fails to deliver a service which was expected for the payment.</p>
<p>In the HTLC case, the payment is <em>conditional</em> on Bob surrendering a secret which is the pre-image of a previous agreed upon hash. Alice signs the HTLC with the condition built in - in such a way that it is revocable by Alice after a time-out if Bob fails to deliver the keys. The rest of the balance of the channel beside the amount paid in the HTLC is unaffected by this payment and behaves as in the single-hop case.</p>
<p>These conditional payments have several advantages. They can be used in things such as atomic swaps and submarine swaps - where the receiving of a pre-image is sufficient to claim a balance of goods elsewhere (another cryptocurrency for example). There are probably many use cases which aren't even explored yet.</p>

CC BY-SA 4.0
2019-08-02T07:22:23.053Z
Though we should point out that Atomic swaps with htlcs as we currently know it yield the free option Problem as pointed out by ZmnSCPxj: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html
Rene Pickhardt
CC BY-SA 4.0
2019-08-02T07:26:04.397Z
That's true for different currencies, but if the two chains are the same curerency (for example, converting from Bitcoin to the Liquid Bitcoin sidechain), then there won't be an issue because they don't trade at different rates.
Mark H
CC BY-SA 4.0
2019-08-02T09:15:54.940Z
Yeah it is really cool how lightning can be used to integrate side chains!
Rene Pickhardt
CC BY-SA 4.0
2019-08-02T07:17:32.723Z
2021-05-01T07:04:27.340Z
2021-05-01T07:04:27.340Z
Mark H
<p>First of all at this point in time the whitepaper is pretty outdated and should only be considered as a rough conceptual guide. <a href="https://github.com/lightningnetwork/lightning-rfc" rel="noreferrer">The Lightning Network Protocol itself is better and more accurately described / specified in the lightning rfc</a></p>

<p>That being said the situation is that even in the single-hop payment case HTLCs are being used. To set up and settle htlcs revokation keys and the revokation system currently play a vital role. The reason is as far as I know to save implementation overhead. </p>

<p>So if Alice wants to pay Bob in a direct channel the process is like that. </p>

<ol>
<li>Bob creates an invoice with a <code>payment_hash</code> that is the hash of some <code>pre_image</code></li>
<li>Bob somehow passes this invoice to Alice. (this can happen over any communication channel)</li>
<li>Alice creates an onion package (which basically just contains a 1 hop payment to Bob</li>
<li>Alice sets up an htlc by sending the onion via an <code>update_add_htlc</code> message to Bob. Alice also offers a signature for the next commitment transaction via the <code>commitment_signed</code> message.</li>
<li>Bob decrypts the onion. sees the payment is for himself and he that he can fulfill the onion.</li>
<li>Bob revok's his hold state by sending a revocation key to alice via the <code>revok_and_ack</code> message.</li>
<li>Bob sends signatures for Alice's new commitment transaction via the <code>commitment_signed</code> message. </li>
<li>Alice revokes her old state with the <code>revoke_and_ack</code> message. </li>
<li>the htlc is settled in a similar way as steps 4 through 7. (It starts with an <code>update fulfill_htlc</code> message send from Bob to Alice and then the state is updated for Alice first and then for Bob. Again recokation keys will be exchanged to get rid of the htlc output and create the state in which the payment has arrived at Bob)</li>
</ol>

<p>A visualization of this process can be found in <a href="https://commons.wikimedia.org/w/index.php?title=File:Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_(BOLT_aka_Lightning-rfc).pdf&amp;oldid=355822713&amp;page=136" rel="noreferrer">slides 136 through 144 of this slide deck</a>. The process itself is <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc" rel="noreferrer">described in more detail in BOLT 02</a></p>

<p>I should also note that there are other suggestions to for a payment channel protocol (<a href="https://blockstream.com/eltoo.pdf" rel="noreferrer">for example Eltoo</a>) which get rid of the penalty based system and the revokation keys but still use htlc's for actually transfering funds (either in multi or in single-hop payments)</p>

<p>Wellcome to this community I hope this technical and detailed answer is not too overwhelming. Please feel free to ask more question if necessary. </p>

CC BY-SA 4.0
2019-08-05T12:51:59.333Z
So In the case of two party with direct payment channel, Are they use combination of RSMC, HTLC contract??
Hoonki
CC BY-SA 4.0
2019-08-05T20:09:31.663Z
Yes. The RSMC is encoded to all HTLC outputs because also those promised funds will be claimed in case of a channel breach
Rene Pickhardt
CC BY-SA 4.0
2019-08-06T02:00:25.157Z
ok. in RSMC there is a timelock concept to impose penalty to party that unilaterally shut down the channel. Also, In htlc there is timelock concept.
So.. what is purpose of the timelock concept in htlc? and
what is relationship between two timelock concept (RSMC, HTLC)?
Hoonki
CC BY-SA 4.0
2019-08-06T07:34:14.210Z
I guess this should be a seperate question. Would you mind posting it? Otherwise I will do it and link it here
Rene Pickhardt
CC BY-SA 4.0
2019-08-08T02:32:19.463Z
Oh i understand after read this https://upload.wikimedia.org/wikipedia/commons/b/b7/Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_%28BOLT_aka_Lightning-rfc%29.pdf
Hoonki
CC BY-SA 4.0
2019-08-02T03:44:50.140Z
2019-08-02T03:44:50.140Z
Rene Pickhardt
<p>I am beginner of lightning network. When i am looking roughly lightning network whitepaper, i was confused about the types of contracts used in single-hop and multi-hop.</p>

<p>As far as I understand, In single-hop(Bidirectional Payment channel) case, it use revocation key concept, and there is no HTLC. And In multi-hop case, it use HTLC concept.</p>

<p>But When I read the example in chapter 4 of the white paper(Example about Alice and Bob), i was confused fact that 'is single-hop case use HTLC?'</p>

<p>Anyone can explain this?</p>

<p>Thank you!</p>

<lightning-network><micropaymentchannels><hash-time-locked-contract>
Single-hop Payment vs Multi-hop payments
Hoonki
# Single-hop Payment vs Multi-hop payments

(Asked by: username_0 on 2019-08-02)

I am beginner of lightning network. When i am looking roughly lightning network whitepaper, i was confused about the types of contracts used in single-hop and multi-hop.

As far as I understand, In single-hop(Bidirectional Payment channel) case, it use revocation key concept, and there is no HTLC. And In multi-hop case, it use HTLC concept.

But When I read the example in chapter 4 of the white paper(Example about Alice and Bob), i was confused fact that 'is single-hop case use HTLC?'

Anyone can explain this?

Thank you!

**Tags:** lightning-network, micropaymentchannels, hash-time-locked-contract


---

## 2 answers

### Answer by username_2 on 2019-08-02. Score: 6 | Accepted answer

First of all at this point in time the whitepaper is pretty outdated and should only be considered as a rough conceptual guide. [The Lightning Network Protocol itself is better and more accurately described / specified in the lightning rfc](https://github.com/lightningnetwork/lightning-rfc)

That being said the situation is that even in the single-hop payment case HTLCs are being used. To set up and settle htlcs revokation keys and the revokation system currently play a vital role. The reason is as far as I know to save implementation overhead.

So if Alice wants to pay Bob in a direct channel the process is like that.

1. Bob creates an invoice with a `payment_hash` that is the hash of some `pre_image`
2. Bob somehow passes this invoice to Alice. (this can happen over any communication channel)
3. Alice creates an onion package (which basically just contains a 1 hop payment to Bob
4. Alice sets up an htlc by sending the onion via an `update_add_htlc` message to Bob. Alice also offers a signature for the next commitment transaction via the `commitment_signed` message.
5. Bob decrypts the onion. sees the payment is for himself and he that he can fulfill the onion.
6. Bob revok's his hold state by sending a revocation key to alice via the `revok_and_ack` message.
7. Bob sends signatures for Alice's new commitment transaction via the `commitment_signed` message.
8. Alice revokes her old state with the `revoke_and_ack` message.
9. the htlc is settled in a similar way as steps 4 through 7. (It starts with an `update fulfill_htlc` message send from Bob to Alice and then the state is updated for Alice first and then for Bob. Again recokation keys will be exchanged to get rid of the htlc output and create the state in which the payment has arrived at Bob)

A visualization of this process can be found in [slides 136 through 144 of this slide deck](https://commons.wikimedia.org/w/index.php?title=File:Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_(BOLT_aka_Lightning-rfc).pdf&oldid=355822713&page=136). The process itself is [described in more detail in BOLT 02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc)

I should also note that there are other suggestions to for a payment channel protocol ([for example Eltoo](https://blockstream.com/eltoo.pdf)) which get rid of the penalty based system and the revokation keys but still use htlc's for actually transfering funds (either in multi or in single-hop payments)

Wellcome to this community I hope this technical and detailed answer is not too overwhelming. Please feel free to ask more question if necessary.

> **Comments:**
> **username_0**: So In the case of two party with direct payment channel, Are they use combination of RSMC, HTLC contract??  
> **username_2**: Yes. The RSMC is encoded to all HTLC outputs because also those promised funds will be claimed in case of a channel breach  
> **username_0**: ok. in RSMC there is a timelock concept to impose penalty to party that unilaterally shut down the channel. Also, In htlc there is timelock concept. So.. what is purpose of the timelock concept in htlc? and what is relationship between two timelock concept (RSMC, HTLC)?  
> **username_2**: I guess this should be a seperate question. Would you mind posting it? Otherwise I will do it and link it here  
> **username_0**: Oh i understand after read this https://upload.wikimedia.org/wikipedia/commons/b/b7/Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_%28BOLT_aka_Lightning-rfc%29.pdf  

---

### Answer by username_1 on 2019-08-02. Score: 4

One reason to use HTLCs for single-hop payments in the Lightning Network would be to make them *indistinguishable* from multi-hop payments to the receiver. This way, the receiver does not know whether it was their direct peer who initiated the payment, or whether they are merely forwarding the payment on for somebody else. Since they look identical to the receiver, the receiver must assume that some other node, who they know nothing about, initiated it.

The way in which HTLCs are created is also useful even for the single-hop use case, because they extend the RSMC model with *conditional* payments. With RSMCs alone, if Alice wishes to pay Bob, she creates a new commitment transaction by reducing the channel balance paid to her, and increasing the balance paid to Bob via the RSMC output. This transaction is then signed by Alice. Assuming that nobody misbehaves, Alice has effectively *already paid* Bob. There is no way this payment can be undone by Alice - for example, if Bob fails to deliver a service which was expected for the payment.

In the HTLC case, the payment is *conditional* on Bob surrendering a secret which is the pre-image of a previous agreed upon hash. Alice signs the HTLC with the condition built in - in such a way that it is revocable by Alice after a time-out if Bob fails to deliver the keys. The rest of the balance of the channel beside the amount paid in the HTLC is unaffected by this payment and behaves as in the single-hop case.

These conditional payments have several advantages. They can be used in things such as atomic swaps and submarine swaps - where the receiving of a pre-image is sufficient to claim a balance of goods elsewhere (another cryptocurrency for example). There are probably many use cases which aren't even explored yet.

> **Comments:**
> **username_2**: Though we should point out that Atomic swaps with htlcs as we currently know it yield the free option Problem as pointed out by ZmnSCPxj: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html  
> **username_1**: That's true for different currencies, but if the two chains are the same curerency (for example, converting from Bitcoin to the Liquid Bitcoin sidechain), then there won't be an issue because they don't trade at different rates.  
> **username_2**: Yeah it is really cool how lightning can be used to integrate side chains!  

---

