Conversation
| _updateLCstate(_lcID, updateParams, _VCroot, _sigA, _sigI) | ||
| } | ||
|
|
||
| uint256 senderIdx = ( |
There was a problem hiding this comment.
This limits the ability of watchers to initiate withdrawals for financial or network hostages
| // certain that's either necessary or desierable. Possibly | ||
| // (probaby?) the `emit DidLCUpdateState(...)` should be moved to | ||
| // the `updateLCstate` function instead of being done here. | ||
| _updateLCstate(_lcID, updateParams, _VCroot, _sigA, _sigI) |
There was a problem hiding this comment.
updateLCState was an entry point to start a challenge to settle to consensus. I am not sure how making it internal and wrapping it in a non-consensus reaching function affects security.
| // channel's current sequence number. | ||
| function withdraw( | ||
| bytes32 _lcID, | ||
| uint256 _balance, |
There was a problem hiding this comment.
this balance is ambiguous, what does it represent, (EDIT) reading the code implies it is the amount you wish to remove, which i think, as you note later, will cause on-chain/off-chain sync issues
| because it will have `channel.state = N`, but the balances in the | ||
| channel will not match balances shown in signed state N. | ||
|
|
||
| Proposal: when there's a withdrawal, assume that there's a |
There was a problem hiding this comment.
This is a large assumption
| 1. Alice wants to withdraw 1 ETH | ||
| 2. She sends state `lc-state(N+1)` to Ingrid, where the amount she | ||
| wants to withdraw has been deducted from the state | ||
| 3. She calls `LedgerChannel.withdraw(...)` with `lc-state(N)` |
There was a problem hiding this comment.
how can you be sure LedgerChannel.withdraw(...) is called with exactly the latest two states? What would this do to byzantine situations?
| `channel.sequence += 1` so its internal sequence number will be | ||
| `N + 1`, and its internal state will match `lc-state(N+1)` | ||
|
|
||
| This would also imply that the `deposit(...)` funciton should be |
There was a problem hiding this comment.
The only reason we have considered a deposit function safe to my knowledge is because you can only lose track off money off-chain (additive updates will only hurt abusers or glitches), rather than allow someone to possibly steal it as is with withdrawals
2 participants
See comments in the code for proposal and questions