forceMove, challenge & default outcome

force-move
1

Hi all,
first some definition of notation (as introduced here:here)

{i} supported state i (chain of valid transitions & signatures present)
{i}* supported state on-chain
{i}-> (i+1)_A participant A made his move (from i to i+1 and signed it)

Now suppose we have a 3 participant channel with participants A,B,C in on-chain state i, A made his next move from the off-chain supported state {j}:

{i}* ->{j} → (j+1)_A

and B does not make his move (might be temporarily offline).

In the docu I read that forceMove challenging is only possible based on supported states (which in my opinion would be {j} but not (J+1)_A.
Is this understanding correct?

This would mean A could only challenge {j} (allowing then in the pessimistic path do defund based on the latest supported state which is OK and secure).

So we have
{i}* ->{j}* ->challenge and (j+1)_A of-chain known

however this would not allow for B coming online and responding such that:
{i}* ->{j}* → (j+1)_A ->(j+2)_B
right?

Or could we challenge as follows (showstopper: j+1 is not a supported state, might have outcome changes B and C do not agree upon):
{i}* ->{j}* → (j+1)_A *
such that B responding gives
{i}* ->{j}* → (j+1)_A * → (j+2)_B*

Therefore, the only solution is A or C challenging {j}
{i}* ->{j}* ->challenge and (j+1)_A of-chain known
now B could of-chain provide his ->(j+2)_B, and C his ->(j+3)_C on top, such that anybody could
checkpoint the resulting supported state {l} (j+1)_A

{i}* ->{j}* ->challenge-> checkpoint {l}*, with transition to {l}=(j+1)_A → (j+2)_B → (j+3)_C

However, in the respond docu, I read that the mover can respond with his move;
B in fact is the off-chain mover, but not the mover to the ‘challengeable’ state {j} (namely required to be a supported state).
A on the other hand could challenge {j} and repsond with his ->(j+1)_A move, which however leaves the channel in open, but not in challenge mode.

You see, I’m confused once again…

Alex

2

Hi Alex,

I’m not entirely sure what your question is, but I’ll do my best here.

it is true that forceMove requires submission of a support proof. If you recall the definition of supported state that you gave:

So, {j} implies {(j+1)_A} as long as the latter is a valid transition from the former, and A is the mover for j+1. So A can challenge to get {j+1}*.

j+1 is a supported state in this case (before it is submitted to chain or otherwise shared by A, they might be the only participant who possesses it). It does not matter that it may have outcome changes that B and C may not like – the point is that the protocol and app rules allow A to unilaterally enforce this state (or force B to move on from it, or force someone to prove they supported a later state, etc).

Does this answer your question?

George

3

Hi George,
yes, that makes this point clear, thank you.

Is there a notion to differ between the two following situations:

a) {j} → (j+1)_A ; with A being the mover
b) {j} → (j+1)_A → (j+2)_B → {j+3}_C = (j+3)_A,B,C = {k}

In a) A is the mover and made his move, so this state can be enforced.
In b) a complete turn has happened, every mover signed

or is this just an artificial choice (assigning a special role in the state where the 1st participant has the next move)? However, for the pre- and post-fund setup (up to n and 2n), this state indeed has a special role…

The background on this question is what has been discussed here.

The case a) above is what I would refer to an atomic game transition in the sense that A makes his move, everybody (inlcuding the adjudicator) could use the game logic to check if it is valid.

Now suppose we have a long of-chain sequence with 3 atomic game transitions between each {}:

{a}* → … → {i} → {j}, with {a}* being a quite old state on chain.
Now A as mover makes his move as in a), B does not respond.

A want’s to challenge J+1; therefore however it is required to be brought on-chain.

What would A now do?
Would A need to provide the full sequence → … → {i} → {j}-> (j+1)_A?
Or would it be sufficient to provide a subset of it?

Alex
P.S.:
Another try to explain what puzzles me:
suppose we have a complex game logic. Suppose we have sate 6 on-chain.
To check a valid transition in the game we need each atomic game transition.
If we have a longer off-chain game sequence, e.g. up to turnNumber 101.
It is not generally possible that the transition form 6 to 101 (without atomic transitions provided) can be checked to really fulfill the game logic.
This in turn means that every participant (it’s wallet) needs to store all transition up to 101…

4

@alexp I think the missing piece in your post above is that a valid atomic game transition from a supported state will always result in a new supported state. In an n-participant channel, a sequence of n atomic game transitions finishing in state s are a support proof for s, and can be used to launch an on-chain challenge. You don’t need to provide a path from the last state the chain saw up to s - if you provide a supported state with a higher turn number, the challenge will be successful. You therefore never need to submit more than n states to the chain, or store more than the last n states.

The case where multiple participants sign the same state can be seen as an optimized way of providing a supported state, leading to lower gas fees in the case where you have to go to chain. It’s not required by the protocol though.

There’s more about the different ways to support a state here, and the logic for checking whether a set of states and signatures form a support proof can be found in the _acceptableWhoSignedWhat function in the force-move contract.

5

No I got it, as documented in the other topic (which lead to the same basic misunderstanding)

Thx
Alex