2

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!

3

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.

  • So In the case of two party with direct payment channel, Are they use combination of RSMC, HTLC contract?? – Hoonki Aug 5 at 12:51
  • 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 Aug 5 at 20:09
  • 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 Aug 6 at 2:00
  • I guess this should be a seperate question. Would you mind posting it? Otherwise I will do it and link it here – Rene Pickhardt Aug 6 at 7:34
  • Oh i understand after read this upload.wikimedia.org/wikipedia/commons/b/b7/… – Hoonki Aug 8 at 2:32
3

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 before 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.

  • 1
    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: lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/… – Rene Pickhardt Aug 2 at 7:22
  • 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 Aug 2 at 7:26
  • Yeah it is really cool how lightning can be used to integrate side chains! – Rene Pickhardt Aug 2 at 9:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.