Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Virtual State Channels whitepaper #451

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Virtual State Channels whitepaper #451

wants to merge 7 commits into from

Conversation

velzevur
Copy link
Contributor

This is according to what had been discussed and described more informally in the first proposition

Copy link
Contributor

@uwiger uwiger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First set of comments

channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
Copy link
Contributor

@uwiger uwiger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more comments

channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved
channels/virtual-state-channels.md Outdated Show resolved Hide resolved

A special case arises when both Virtual State Channel participants agree on an
off-chain update and one of them provides it to the intermediary while the
other does not. Since Channel state can only be updated with a mutual
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But would this happen? Didn't we say that the initiator of the update sends to the intermediary, and the intermediary forwards it to the other parent channel? This would be more similar to how it is on the chain (only one party posts to the chain, while the other gets notified of the on-chain change).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, it is the other way around: VSC participants create their updates and each of them provides them to the intermediary in their parent State Channels.

The other way around actually imposes a bit of a risk for the intermediary, namely:

  1. Alice and Bob agree on stateX
  2. Alice gives Ingrid the stateX
  3. Ingrid gives Bob stateX but Bob refuses to update their VSC object

What shall Ingrid do now? In order for her to be safe, she must include that in their channel so she shall force progress it on-chain. On the other hand, Bob is in a possession of the update, already signed by Ingrid, and question is this gives him any advantage or not. If Ingrid ever authenticates an alternative update with the same round, she is in trouble.

A safer approach I am slightly in favour of would be both Alice and Bob provide her with the VSC off-chain update they have for her. If just one of them does it and the other does not, Alice could gently poke the non-cooperative one with a soft-force progress action or go directly on-chain forcing it there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I take that back. This is part of the category of problems A proposes something authenticated to B, B refuses but is still in possession of the authenticated object . The worst thing could happen is Bob to force progress based on that particular state - hence approving it. The flow who tells who what should not really matter that much and we need propagation of messages in multy intermediary scenarios anyway.

The described approach is not mandatorary but prefered for the symmetry it provides.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the safer approach would mean that Ingrid gets an update from Alice, and then waits for the same tx to be provided by Bob, eventually perhaps poking with a soft-FP. If Ingrid instead performs the soft-FP right away, Bob would be waiting in much the same way as in the on-chain case, and refusing would either have the result that Alice FPs on the parent chain/channel or simply solo-closes and declares the VSC uncooperative.

@radrow
Copy link
Member

radrow commented Nov 30, 2022

Is this still a thing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants