How to properly reject an update over a state channel

Protocol Features & Updates State Channels
1

Hi guys, while working on our state channel application we face the following scenario:

Application is under base-aepp. User A initiates a transfer update from B to A, previously arranged. When the update is sent by A, the user B is asked by the base-aepp to confirm the update by signing it. At this point, user B decides to change his mind and cancels the transaction.
Now, the channel becomes unusable (no messages can be received or sent); we assume in the “awaiting_signing” state for the duration of the timeout which is 500000 ms by default.

a. Is there a proper way to reject the update which does not involve any timeout? (in both scenarios, standalone nodejs application and base-aepp hosted).
b. Is it possible that if a channel is in the mentioned timeout (awaiting for signing), and ONE of the endpoints disconnects and connects back (no reconnection) the new opened channel will be in the same state? (perhaps reusing the same channel)

Thanks in advance.

2 Likes
2

Speaking for the FSM, there seem to be a bug in that the fsm stays in the current state after a failed signature verification. The simplest way would otherwise have been to reply to the signing request, but not adding a signature.

There is a sneaky way to abort: send a competing update request. The FSM will know that there is already an ongoing request, and will abort that one with a ‘conflict’ message.

Currently ‘handle_update_conflict()’ is something of a goto for handling errors in the FSM. It should be enhanced with the possibility of providing rejection reasons, but should also be what happens on a failed signature validation.

1 Like
3

I think its quite cool to also share the link to the ticket here like you did in devchat.

Hope this solves your problem for now @hernandp!

1 Like
4

Thanks guys, regarding this:

  • Can we rely on the signing timeout to expire or the FSM wont return to open state even when the timer expires?

  • If this is the case, cancelling a transaction for our base-aepp hosted app would include workarounds mentioned here (issuing a conflicting update) .
    Another fast hack idea:
    Could be possible to make the base-aepp to enter “auto-signing” mode for a specific application or scenario [e.g: just channel updates] ? For example, once the user confirms the account access, channel updates could be “autosigned” avoiding the “handling cancellation of an update, use the workaround,etc” issue.

Thanks again,
Hernan

5

Unfortunately, the FSM terminates if a state timer times out. We know full well this is sub-optimal (to say the least), but it hasn’t made the cut for things to prioritize until now.

2 Likes
6

@hernandp For reference the PR Improve client protocol error handling in SC FSMs has been merged. The corresponding documentation change is in review.

1 Like