Single-hop Payment vs Multi-hop payments

Question

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!

Answer 1

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

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. The process itself is described in more detail in BOLT 02

I should also note that there are other suggestions to for a payment channel protocol (for example Eltoo) 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.

Answer 2

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.