3

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

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

Improve this question
3
  • 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 ♦
    May 27, 2020 at 0:02
  • 1
    Ya I have corrected that
    – Subhra Mazumdar
    May 28, 2020 at 4:54
  • Great, thanks! I updated the title, made a little formatting change to highlight the question in the post and reopened it.
    – Murch ♦
    May 28, 2020 at 16:13

2 Answers 2

Reset to default
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) 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 ?

Improve this answer
1
  • 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
    May 23, 2020 at 15:57
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.

Improve this answer
1
  • 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
    May 23, 2020 at 6:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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