2
I received an invoice from node Z and my node (A) suggests me 4 possible routes.
If the first two routes fail, are there cases in which funds can get stuck in one of these routes until the HTLC expires?
Which are these cases? Are they avoidable?
If I try the routes with a failed hash can I avoid to have my funds locked in a failed attempt (or is it better to test routes with a few millisatoshis)?
3
The funds in the respective HTLC's get stuck for a time-out period if the payment_pre-image doesn't propagate back along the route to your originating channel. There is no guarantee beforehand that this propagation will be successful. That is why HTLC(sent)'s are always signed together with a respective time-out transaction, with a signed input that spends this HTLC output in such a failure scenario.
Testing with smaller amounts as you propose ensure that only smaller amounts are captured in the HTLC outputs of the commitment transactions in your channel, so only a smaller amount would be "stuck" (this HTLC output is spendable later by the respective time-out transaction during a channel close). So until the time-out period is over, you have the remaining channel capacity to transact with.
1
This question goes back to this discussion: https://twitter.com/renepickhardt/status/1082192531025219586 so the question is if HTLCs have to wait for a timeout even if "bad signature error" is returned. According to SPHINX the routing nodes should not be able to see the content of the error message. So I guess your answer is also correct for that particular case. Still I wanted to verify by reading the code. Another issue is that every channel can only hold about 400 HTLC outputs. so this might DoS the network.
– Rene Pickhardt – 2019-01-07T14:41:01.623Hm - even with a “fake” hash “routing”, there is no guarantee that subsequent payments along the same route will succeed. It is just a past indicator, albeit a recent one. – James C. – 2019-01-07T14:51:13.640
Only the recipient of the payment route can revoke HTLC's without a cost, given that all intermediary nodes do not lose/gain from cooperatively resetting in/outbound HTLC pairs. The 400 HTLC limit also serves as DOS protection, since this limit introduces an routing opportunity cost to an attacker. – James C. – 2019-01-07T18:23:10.487
So each one of the failed attempts lock some fund for the HTLCs expiry time? Wow. Better to set a short expiry time if I understood correctly and maybe to test the route with fake HASHes and small amounts. – Gabriele Domenichini – 2019-01-08T08:22:38.887