Show errors instantly

[kilrau]

Intro

E.g. payment calls hanging for several minutes, before erroring in "Internal server error". I have experienced this myself and I believe @offerm brought it up before.

Only errors that are thrown instantly are on initial validation (e.g. insufficient balance). Everything that passes initial validation is not instant. I understand this is not an easy problem to solve, because feedback from failures on the route if someone on the route is not responsive only return after lock expirmes. Consider failing locked transfers earlier (timeout), consider reporting back on the rest of the fucntioning route.

Consider moving away from active "refund payments" as way to notify about a failed route" to cancel locked payments and notify via p2p messages.

PFS should improve (due to higher routing success), but definitely will not solve this.

Problem Definition

Above.

System Description

N/A

[LefterisJP]

@palango @Dominik1999 Would PFS usage improve our error reporting for not being able to find routes? I believe it should.

[palango]

Would PFS usage improve our error reporting for not being able to find routes? I believe it should.

I should get better as the quality of the routes tried increases, but we can never guarantee that the routes actually work. So the point made in the issue still holds.

[LefterisJP]

but we can never guarantee that the routes actually work. So the point made in the issue still holds.

Yep that's what I meant. That it would at least improve the current situation.

[kilrau]

Another reason why cancelling locked payments is desirable (and not refunding): #4150 (comment)

[hackaugusto]

There are a few approaches that can be taken to improve this (roughly ordered from the easiest to hardest to implement):

• We can reduce the time available for the protocol to finish, right now reveal_timeout is around 10min, and we use that as the amount of time available for the off-chain protocol to finish.
• The initiator can set a timeout to expire the payment after a timeout (probably in milliseconds). If the secret is not revealed until the timeout is reached the ActionCancelPayment is dispatched and the secret is erased. Effectively the payment failed, the problem here is that the tokens are locked until the lock expires. This can be used by Raiden if it controls the secret or by the xud if Raiden is the first leg.
• When an initiator receives a refund there are only two options, a new route is tried (with the same or a new secret) or the current payment is cancelled. If the current payment is cancelled then the API can return right away Initiator: Split Refund transfer handling #4257 (the payment can be cancelled with a secret reveal or not, the secret should be reviewed if the user can recover a sufficient amount of its initial funds).
• We can try to further reduce the reveal_timeout. This setting is always tricky because it handles blockchain congestion. We could do a few things here:

1. With a fixed reveal_timeout:
   • The gas_price can be constant. Here than the reveal_timeout would have to be quite large, set for the worst case. (This is not a good option).
   • The gas_price can vary, and under congestion the cost of registering a secret would increase. This is the current approach, right now we assume the gas_price chosen by web3 will result in a transaction mined within 5min, we add a 5min margin on that, this gives a minimum lock expiration of 10min, maybe this can be closer to the initial 5min (related PR Increase the reveal timeout #2670).
2. With a variable reveal_timeout:
   • The gas_price can be constant and the expiration would vary. The advantage here would be cost efficiency, and fast errors when there is no congestion, the problem is that it would be hard to properly find a path in the network.

• We can improve the protocol so that refunds don't require funds in the backwards direction, like they currently do. Then refunds would only need the previous hop to be online. This however will not be available for Alderaan and will required new smart contracts. Proposal for a new type of refund/cancellation raiden-contracts#1216

Related issue: #451

Edit: One important point here. The behavior on some of these options would be surprising to the user, on the cases were the payment is known to have failed but the lock is not expired yet, the channel capacity will not change. Additionally, this can have weird interactions with how we prevent repeated payments. For these cases I would prefer a separate REST API endpoint.