Abstract
In #3024 the emit of the EventPaymentSentFailed event was changed to happen at the same time as the EventUnlockFailed. We should add a similar event that can signal a failed payment earlier.
Motivation
The reason for the change of the EventPaymentSentFailed emit is that
This change however makes the failure event consistent with the update in balance, since the byzantine node is the target, which is not necessarily the next hop, and we need to wait for the lock to expire before removing it.
However,
on the other hand it might be nice to be able to inform the user as early as possible that the payment failed, even if the funds are still locked.
Augusto the propsed the following solution:
I really think we should target a consistent view of the state as much as possible, the system is hard enough to understand when things are consistent. However, it can be definitely useful to inform a user that a transfer will not be completely because of ByzantineBehavior, so my suggestion would have two different events, keep this one here, which exposes a consistent view, and add a new one to inform the user when something unexpected happened (like the target sending the wrong secret request).
Specification
Add a new event to signal that byzantine behaviour was spottet and the payment failed therefore.
Backwards Compatibility
Should not be backwards incompatible.
Abstract
In #3024 the emit of the
EventPaymentSentFailedevent was changed to happen at the same time as theEventUnlockFailed. We should add a similar event that can signal a failed payment earlier.Motivation
The reason for the change of the
EventPaymentSentFailedemit is thatHowever,
Augusto the propsed the following solution:
Specification
Add a new event to signal that byzantine behaviour was spottet and the payment failed therefore.
Backwards Compatibility
Should not be backwards incompatible.