<p>The failure message must go along the same route it came, because any intermediate step does not know where the payment was originally sent from. Every hop only knows the previous and next hops in the sequence, and so the only option it has is to return the information to the previous hop on the route.</p>

CC BY-SA 4.0
2019-04-08T13:49:05.830Z
alright thanks a lot. I saw this and wasn't so sure so just wanna check. Thanks again.
demid
CC BY-SA 4.0
2019-04-08T14:10:59.040Z
i got one more question: since each hop knows the previous and next hops, would that mean the intermediate node needs to record every payment's information on this hop? wouldn't that create large overhead? or the hopping information is not stored on the node. Thanks a lot!
demid
CC BY-SA 4.0
2019-04-08T14:20:06.363Z
Some information must be kept around because it is necessary to keep commitment transactions for all past channel states (in case other party broadcasts an old state), and the commitment and associated htlcs require the payment hash. The other session information for each payment forwarding only needs to be held for the duration that the HTLC is in flight.
Mark H
CC BY-SA 4.0
2019-04-08T13:46:38.570Z
2019-04-08T13:46:38.570Z
Mark H
<p>In the Lightning Network, the intermediate hop between the sender and receiver checks for possible errors(like if it has enough balance). And if there is, it sends an <code>HTLCFail</code> message back to the sender. </p>

<p>I was wondering if the <code>HTLCFail</code> message is sent back to the sender via the path it comes from, or it's routed by some new random path as long as it can go back and let the sender know this path cannot route?</p>

<blockquote>
  <p>Payment relay (intermediate hop). H checks for possible errors (e.g., it checks whether it has enough
  balance to forward the payment). If there are errors, it sends an HTLCFail message back to S , failing
  the HTLC; otherwise, it sends an HTLCAdd message to R . (This step occurs multiple times in the general
  case of a payment going through multiple intermediate hops.)</p>
</blockquote>

<lightning-network><lightning-network-daemon><lightning-routing><lightning-rfc>
Does the `HTLC fail` routed back to sender using same path if intermediate node does not have enough capacity?
demid
# Does the `HTLC fail` routed back to sender using same path if intermediate node does not have enough capacity?

(Asked by: username_0 on 2019-04-08)

In the Lightning Network, the intermediate hop between the sender and receiver checks for possible errors(like if it has enough balance). And if there is, it sends an `HTLCFail` message back to the sender.

I was wondering if the `HTLCFail` message is sent back to the sender via the path it comes from, or it's routed by some new random path as long as it can go back and let the sender know this path cannot route?

> Payment relay (intermediate hop). H checks for possible errors (e.g., it checks whether it has enough
> balance to forward the payment). If there are errors, it sends an HTLCFail message back to S , failing
> the HTLC; otherwise, it sends an HTLCAdd message to R . (This step occurs multiple times in the general
> case of a payment going through multiple intermediate hops.)

**Tags:** lightning-network, lightning-network-daemon, lightning-routing, lightning-rfc


---

## 1 answers

### Answer by username_1 on 2019-04-08. Score: 1 | Accepted answer

The failure message must go along the same route it came, because any intermediate step does not know where the payment was originally sent from. Every hop only knows the previous and next hops in the sequence, and so the only option it has is to return the information to the previous hop on the route.

> **Comments:**
> **username_0**: alright thanks a lot. I saw this and wasn't so sure so just wanna check. Thanks again.  
> **username_0**: i got one more question: since each hop knows the previous and next hops, would that mean the intermediate node needs to record every payment's information on this hop? wouldn't that create large overhead? or the hopping information is not stored on the node. Thanks a lot!  
> **username_1**: Some information must be kept around because it is necessary to keep commitment transactions for all past channel states (in case other party broadcasts an old state), and the commitment and associated htlcs require the payment hash. The other session information for each payment forwarding only needs to be held for the duration that the HTLC is in flight.  

---

