-
Notifications
You must be signed in to change notification settings - Fork 76
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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
Co-Authored-By: Ulf Wiger <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more comments
|
||
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 |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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:
- Alice and Bob agree on stateX
- Alice gives Ingrid the stateX
- 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-Authored-By: Ulf Wiger <[email protected]>
Is this still a thing? |
This is according to what had been discussed and described more informally in the first proposition