<blockquote>
  <p>In HTLC, after all the parties have locked their funds in the contract, claiming payment happens in a reverse way, starting with the receiver who reveals the preimage of the corresponding payment hash. What will be the problem if it had started with the sender?</p>
</blockquote>

<p>Firstly the sender has technically nothing to claim, secondly the receiver is the only one <strong>able</strong> to reveal the preimage in the first place.</p>

<blockquote>
  <p>After the receiver confirms receipt of the contract, it sends an acknowledgment to sender. Sender releases preimage</p>
</blockquote>

<p>Do you mean the receiver would then hand the preimage to the sender ? This adds even more interactivity (<a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002552.html" rel="nofollow noreferrer">if not using the Lightning Network itself to transfer the information</a>) and also drops (partially ?) the Proof Of Payment.</p>

<p>I didn't think too hard about it but it may also open up a lot of other issues, what would be the rationale for doing so ?</p>

CC BY-SA 4.0
2020-05-23T15:57:53.107Z
Yes without the interaction, sender will not be able to figure out whether receiver has accepted the incoming contract for claiming payment or not. Had it not been the case, then sender would have started the transfer of fund but there might be parties in between who don't forward the payment. Hence for the atomicity of payment, this step is needed. I am thinking about a payment protocol with some incentivization mechanism and for that, a reverse payment looks feasible rather than settling payment from receiver.
Subhra Mazumdar
CC BY-SA 4.0
2020-05-23T13:48:51.233Z
2020-05-23T14:03:16.790Z
2020-05-23T14:03:16.790Z
Antoine Poinsot
<p>I think you have answered your question yourself. If all nodes would behave honestly and in good faith your process would work. But in that case we would not need to go through the hustle of setting up htlcs to begin with but we could just forward money by changing the balances in each channel. The whole point of using htlcs is to make the payment process atomic and prevent nodes along the path from stealing funds.</p>
<p>Other than that I do not see any additional flaws.</p>
<p>Offtopic:</p>
<p>Looking at your recent post on the mailing list (c.f: <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002718.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002718.html</a> ) I wonder if this idea of &quot;forwarding a second preimage&quot; in addition to the current process of &quot;releasing a preimage&quot; could be constructed to prevent griefing attacks because the sender could enforce settling the htlc in case someone stalls the process. But the way how I  imagine such a solution right now, it would basically run into the same problems as you already described in your initial question. It might be interesting to investigate if PTLCs (with adoptor signatures and payment decorellation) could be used to identify the griefing node and use such a process.</p>

CC BY-SA 4.0
2020-05-23T06:47:54.193Z
Thanks for the reply. Yes we are looking into some other methods of countering reverse-griefing. The idea of second preimage sounds good!
Subhra Mazumdar
CC BY-SA 4.0
2020-05-23T06:41:05.300Z
2020-10-26T12:11:01.077Z
2020-10-26T12:11:01.077Z
Rene Pickhardt
<p>In HTLC, after all the parties have locked their funds in the contract, claiming payment happens in a reverse way, starting with the receiver who reveals the preimage of the corresponding payment hash. </p>

<p><strong>What would be the problem if it had started with the sender?</strong> After the receiver confirms receipt of the contract, it sends an acknowledgment to sender. Sender releases preimage, timelock set in increasing order across the path, contract initiated by sender having the least locktime. Receiver is the last node to settle the payment.</p>

<p><a href="https://i.sstatic.net/6cSbF.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/6cSbF.png" alt="enter image description here"></a></p>

<p>For reference, I am adding a picture so that one can visualize what I am trying to say.</p>

CC BY-SA 4.0
2020-05-27T00:02:07.120Z
Hello Subhra,
Stackexchange is a question and answer platform. Topics are started by someone creating a question post and then getting one or more competing answers. Please see our [tour] for an illustration. This means that a question post should _only_ post the question, however, you've also included your own answer. This turns your "question" post into a "please check my answer" post which makes it difficult for others to address your question. Please edit this post to reduce it to the question and post your answer as an answer below.
Murch
CC BY-SA 4.0
2020-05-28T04:54:41.317Z
Ya I have corrected that
Subhra Mazumdar
CC BY-SA 4.0
2020-05-28T16:13:36.173Z
Great, thanks! I updated the title, made a little formatting change to highlight the question in the post and reopened it.
Murch
<lightning-network><lightning-routing><micropayments><hash-time-locked-contract>
Why do multihop LN payments start settling from the recipient's end?
Subhra Mazumdar
# Why do multihop LN payments start settling from the recipient's end?

(Asked by: username_0 on 2020-05-23)

In HTLC, after all the parties have locked their funds in the contract, claiming payment happens in a reverse way, starting with the receiver who reveals the preimage of the corresponding payment hash.

**What would be the problem if it had started with the sender?** After the receiver confirms receipt of the contract, it sends an acknowledgment to sender. Sender releases preimage, timelock set in increasing order across the path, contract initiated by sender having the least locktime. Receiver is the last node to settle the payment.

[![enter image description here](https://i.sstatic.net/6cSbF.png)](https://i.sstatic.net/6cSbF.png)

For reference, I am adding a picture so that one can visualize what I am trying to say.

**Tags:** lightning-network, lightning-routing, micropayments, hash-time-locked-contract

> **Comments:**
> **username_1**: Hello username_0, Stackexchange is a question and answer platform. Topics are started by someone creating a question post and then getting one or more competing answers. Please see our [tour] for an illustration. This means that a question post should _only_ post the question, however, you've also included your own answer. This turns your "question" post into a "please check my answer" post which makes it difficult for others to address your question. Please edit this post to reduce it to the question and post your answer as an answer below.  
> **username_0**: Ya I have corrected that  
> **username_1**: Great, thanks! I updated the title, made a little formatting change to highlight the question in the post and reopened it.  

---

## 2 answers

### Answer by username_2 on 2020-05-23. Score: 1

> In HTLC, after all the parties have locked their funds in the contract, claiming payment happens in a reverse way, starting with the receiver who reveals the preimage of the corresponding payment hash. What will be the problem if it had started with the sender?

Firstly the sender has technically nothing to claim, secondly the receiver is the only one **able** to reveal the preimage in the first place.

> After the receiver confirms receipt of the contract, it sends an acknowledgment to sender. Sender releases preimage

Do you mean the receiver would then hand the preimage to the sender ? This adds even more interactivity ([if not using the Lightning Network itself to transfer the information](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002552.html)) and also drops (partially ?) the Proof Of Payment.

I didn't think too hard about it but it may also open up a lot of other issues, what would be the rationale for doing so ?

> **Comments:**
> **username_0**: Yes without the interaction, sender will not be able to figure out whether receiver has accepted the incoming contract for claiming payment or not. Had it not been the case, then sender would have started the transfer of fund but there might be parties in between who don't forward the payment. Hence for the atomicity of payment, this step is needed. I am thinking about a payment protocol with some incentivization mechanism and for that, a reverse payment looks feasible rather than settling payment from receiver.  

---

### Answer by username_3 on 2020-05-23. Score: 1

I think you have answered your question yourself. If all nodes would behave honestly and in good faith your process would work. But in that case we would not need to go through the hustle of setting up htlcs to begin with but we could just forward money by changing the balances in each channel. The whole point of using htlcs is to make the payment process atomic and prevent nodes along the path from stealing funds.

Other than that I do not see any additional flaws.

Offtopic:

Looking at your recent post on the mailing list (c.f: <https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002718.html> ) I wonder if this idea of "forwarding a second preimage" in addition to the current process of "releasing a preimage" could be constructed to prevent griefing attacks because the sender could enforce settling the htlc in case someone stalls the process. But the way how I imagine such a solution right now, it would basically run into the same problems as you already described in your initial question. It might be interesting to investigate if PTLCs (with adoptor signatures and payment decorellation) could be used to identify the griefing node and use such a process.

> **Comments:**
> **username_0**: Thanks for the reply. Yes we are looking into some other methods of countering reverse-griefing. The idea of second preimage sounds good!  

---

