<p>Unless I have misunderstood the LN, the R value gets disclosed publicly when D accepts the payment, allowing the entire backchain to claim their parts.</p>

CC BY-SA 3.0
2017-10-27T16:13:31.090Z
Yes, I am aware of that, but say D claims the payment and discloses R and right before that C disappears (and does not come back for the duration of the HTLC). Thus, B can claim funds twice. Is this correct and/or realistic? Or is the whole process so fast that this scenario is unlikely?
crypto_rob
CC BY-SA 3.0
2017-10-27T18:26:42.990Z
yes, if C disappears after having sent value out, and before D claims the value - and stays gone until after the timelock expires, then B can claim the value from A and reclaim the value from B.
Jonathan Silverblood
CC BY-SA 3.0
2017-10-27T18:56:06.433Z
Alright, that's exactly how I thought it would work. How fast does this transaction stream happen? How fast would C have to disconnect after relaying the transaction for this to happen? I assume ms or even less.
crypto_rob
CC BY-SA 3.0
2017-10-27T19:36:36.490Z
depends mostly on the network latencies of involved parties. likely to be sub-second in most cases, but could go up to a few seconds in less than ideal conditions.
Jonathan Silverblood
CC BY-SA 3.0
2017-10-27T19:43:28.280Z
Also, I guess that if, say B tried to force C to disconnect via some sort of attack in order to get double pay, C could commit the commitment tx and thus "pull out" of the channel. Sorry, sort of digressing into more of a discussion than a Q/A.
crypto_rob
CC BY-SA 3.0
2017-10-27T19:44:18.403Z
if you are considering this from an adversial perspective, remember that the timelock is significantly longer, and that if C detects the condition they will likely have well enough time to manually copy the transaction and broadcast it from a different node, meaning that to successfully do this as an attack where you control B and D you would need to render C completely incapable of taking action.
Jonathan Silverblood
CC BY-SA 3.0
2017-10-27T19:51:05.420Z
Getting warnings about length of comment section extending too far. I think you've got me going in right direction, thanks!
crypto_rob
CC BY-SA 3.0
2018-03-23T00:22:15.653Z
LN will have a monitoring service, C can give it sufficient information for the monitoring service to recover the fund for C if he has not done it.
Helin Wang
CC BY-SA 3.0
2017-10-27T12:36:01.860Z
2017-10-27T12:36:01.860Z
Jonathan Silverblood
<p>If the transaction cannot resolve before the CLTV value of the HTLC runs out the peers will be refunded (the pending HTLCs cancelled) and the transaction will be cancelled.</p>
<p>If C is not there to receive R funds will not move so there is no need for force closures, but the funds will be stuck on the online channels as well for that period of time.
The online channels will be able to propagate payments in the meantime given there is more liquidity available and the number of pending HTLC-s is below the set limit.</p>
<p>See the situation where C would be online to receive R and go offline before propagating to B discussed in:
<a href="https://bitcoin.stackexchange.com/questions/90862/what-happens-if-r-is-not-revealed-by-one-of-lightning-network-nodes-payment-ca/90863#comment104007_90863">What happens if R is not revealed by one of Lightning Network nodes? (Payment cancelation)</a></p>

CC BY-SA 4.0
2021-04-15T10:07:40.880Z
2021-04-15T10:07:40.880Z
openoms
<p>I think I have a general understanding of how the Lightning Network works. However, I was having a little difficulty in understanding what happens when a node in the middle of a "path" suddenly goes dormant, or offline for a long time. To clarify my question, consider the following example:</p>

<ol>
<li>A wants to make a payment of 1 BTC to D.</li>
<li>A finds a path from A --> B --> C --> D.</li>
<li>D generates an R and sends H = hash(R) to A</li>
<li>A creates HTLC of 1.002 BTC with B.</li>
<li>B creates HTLC of 1.001 BTC with C.</li>
<li>C creates HTLC of 1 BTC with D.</li>
<li>D unlocks HTLC, receives 1 BTC, and then tells R to C.</li>
</ol>

<p>However, what if C is suddenly offline meaning C won't be there to receive R from D and thus stops the flow of R back through the path. I would assume that the HTLC's between A and B and B and C run out and so A and B are refunded. </p>

<p>So, would C lose out? Would A have just made a "free" transaction? I assume this is a fast process, but is it likely such an event occurs where a middle node in an LN transaction just goes down for a long while?</p>

<lightning-network><lightning-routing><ln-node-reliability>
In the Lightning Network, what happens if a "middle node" suddenly goes dormant for a long while?
crypto_rob
# In the Lightning Network, what happens if a "middle node" suddenly goes dormant for a long while?

(Asked by: username_0 on 2017-10-27)

I think I have a general understanding of how the Lightning Network works. However, I was having a little difficulty in understanding what happens when a node in the middle of a "path" suddenly goes dormant, or offline for a long time. To clarify my question, consider the following example:

1. A wants to make a payment of 1 BTC to D.
2. A finds a path from A --> B --> C --> D.
3. D generates an R and sends H = hash(R) to A
4. A creates HTLC of 1.002 BTC with B.
5. B creates HTLC of 1.001 BTC with C.
6. C creates HTLC of 1 BTC with D.
7. D unlocks HTLC, receives 1 BTC, and then tells R to C.

However, what if C is suddenly offline meaning C won't be there to receive R from D and thus stops the flow of R back through the path. I would assume that the HTLC's between A and B and B and C run out and so A and B are refunded.

So, would C lose out? Would A have just made a "free" transaction? I assume this is a fast process, but is it likely such an event occurs where a middle node in an LN transaction just goes down for a long while?

**Tags:** lightning-network, lightning-routing, ln-node-reliability


---

## 2 answers

### Answer by username_1 on 2017-10-27. Score: 1 | Accepted answer

Unless I have misunderstood the LN, the R value gets disclosed publicly when D accepts the payment, allowing the entire backchain to claim their parts.

> **Comments:**
> **username_0**: Yes, I am aware of that, but say D claims the payment and discloses R and right before that C disappears (and does not come back for the duration of the HTLC). Thus, B can claim funds twice. Is this correct and/or realistic? Or is the whole process so fast that this scenario is unlikely?  
> **username_1**: yes, if C disappears after having sent value out, and before D claims the value - and stays gone until after the timelock expires, then B can claim the value from A and reclaim the value from B.  
> **username_0**: Alright, that's exactly how I thought it would work. How fast does this transaction stream happen? How fast would C have to disconnect after relaying the transaction for this to happen? I assume ms or even less.  
> **username_1**: depends mostly on the network latencies of involved parties. likely to be sub-second in most cases, but could go up to a few seconds in less than ideal conditions.  
> **username_0**: Also, I guess that if, say B tried to force C to disconnect via some sort of attack in order to get double pay, C could commit the commitment tx and thus "pull out" of the channel. Sorry, sort of digressing into more of a discussion than a Q/A.  
> **username_1**: if you are considering this from an adversial perspective, remember that the timelock is significantly longer, and that if C detects the condition they will likely have well enough time to manually copy the transaction and broadcast it from a different node, meaning that to successfully do this as an attack where you control B and D you would need to render C completely incapable of taking action.  
> **username_0**: Getting warnings about length of comment section extending too far. I think you've got me going in right direction, thanks!  
> **username_2**: LN will have a monitoring service, C can give it sufficient information for the monitoring service to recover the fund for C if he has not done it.  

---

### Answer by username_3 on 2021-04-15. Score: 2

If the transaction cannot resolve before the CLTV value of the HTLC runs out the peers will be refunded (the pending HTLCs cancelled) and the transaction will be cancelled.

If C is not there to receive R funds will not move so there is no need for force closures, but the funds will be stuck on the online channels as well for that period of time.
The online channels will be able to propagate payments in the meantime given there is more liquidity available and the number of pending HTLC-s is below the set limit.

See the situation where C would be online to receive R and go offline before propagating to B discussed in:
[What happens if R is not revealed by one of Lightning Network nodes? (Payment cancelation)](https://bitcoin.stackexchange.com/questions/90862/what-happens-if-r-is-not-revealed-by-one-of-lightning-network-nodes-payment-ca/90863#comment104007_90863)


---

