Let's say we have route of 3 hops A -> B -> C -> D (A pays D). And in the middle of payment (revealing secret R stage) node C disappear from network. In this case B will be not able to finalise payment because he don't know secret of hashlock.

I know that there is timelock, so most probably node B will need to start closing channel procedure (channel B -> C).

But what is happening with payment? Is it accepted/rejected/hanging? What is happening with A->B and C->D channels? Will they be hanging until situation with B->C is resolved? Or there is some kind of payment cancelation protocol?

1 Answer 1


The situation is less worse than you seem to assume. If node C disappears the channel A,B won't be affected. Also there is no direct need to affect the channel B, C and C, D. So most channels will stay open.

The payment process is a two stage process and it depends during which stage of the process node C disappears to see what happens and how nodes react.

First stage: setting up htlcs from A to D. If C disappears before the htlcs have reached C the onion /payment is cancelled. No channel will be closed. Otherwise the resolution of the second stage takes place.

Second stage: preimage is propagated. Node D might force close the channel to settle the htlc on chain. In that case B could also see the preimage on chain an settle off chain. C has time to come back and claim money from B. If C is away too long C will have lost money sich B will have won. If D has settled before C disappears C will not be incentivesed to disappear as C could not get Reimbursed by B.

So we see the only channel that might break in such a situation is the C,D channel. But in any cases only C can loose money / funds by disappearing. This C is Incentivised to stay online and be responsive

  • I was talking more about situation when C gets preimage from D and then is not propagating it forward. So D in this case should know that he done his work and accepted payment. But middle party B still don't have preimage and is unhappy. How long will B wait for preimage? If it not get's pre-image what it should do? Closing channel without pre-image to force C reveal R? is it even possible?
    – Jaro
    Commented Oct 8, 2019 at 15:09
  • 1
    If C has the preimage from D. C has paid D. If C goes away C will loose money as C is not reimbursed by B. B does not mind. If B does not get the preimage and pay C then B does not need to get reimbursed by A. However since the timelocks are there A and B might remove their pending htlc after a timelock to free up funds. At that point B should also have removed the HTLC with C. So if C is gone B only has the option to force close the BC channel to prevent C from setteling the htlc later. If that helps I will edit my answer Commented Oct 8, 2019 at 15:55
  • > If C goes away C will loose money as C is not reimbursed by B. B does not mind. > ... > So if C is gone B only has the option to force close the BC channel to prevent C from setteling the htlc later. Hmm, C has preimage and last biggest tx from B. So when BC channel is going to be force close, then C can show newest tx. In this case his version wins and A,B channel also can't cancel payment. And if they already did that, they should rebalance, otherwise B will loose money. Or I'm here wrong somehow? P.S. I do see that C,D channel is not affected.
    – Jaro
    Commented Oct 13, 2019 at 8:31
  • The time locks prevent the risk for the AB channel. If the timelock passed B spends the htlc output onchain (from the force close) and the htlc in the AB channel will be removed without settling. Thus as mentioned before the AB channel is not affected and B won't loose money. C looses money if C is not following the protocol (also mentioned before) Commented Oct 13, 2019 at 18:21
  • 1
    Yes but the channel can still be used for other payments. There is just this particular htlc locking up the liquidity of that payment. Other than that the channel will not be affected Commented Oct 15, 2019 at 11:19

Your Answer

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

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