Supporting channel participants not holding ETH or ERC20 tokens

[pirapira]

In some use-cases (for example light client), the channel participants do not control ETH or the transferred ERC20 tokens. In those use-cases, the channel participants only sign balance proofs (withdraw proofs, etc) and delegate the Ethereum transaction signature to other parties.

This issue keeps track of

• modifying settleChannel() so that the tokens can be transferred to other accounts that the token owners specify
  • this modifies the balance proof signature scheme. When a participant signs a balance proof, the participant needs to add one field address beneficiary.
• modifying setTotalWithdraw() so that the tokens can be transferrred to another acccount
• modifying unlock() so that the tokens can be sent to another account
  • use the same addresses provided in settleChannel()?
• modifying closeChannel() so that the function can be called by a third-party

[pirapira]

When we modify closeChannel(), we need to be careful in the client once it signs the close proof.

Currently, in the client, the channel is assumed to be closed before the closeChannel() transaction is sent out to the Ethereum network. After the change, the client needs to assume that the channel is closed, once the client signs the signature for closing the channel.

[pirapira]

Modifying unlock() alone is no good because the not-unlocked tokens go back to the sender (subkey).

[pirapira]

The settlement function takes too many arguments after this. The settlement function has to use the V2 ABI first (#1129).

[andrevmatos]

Related: #352

[christianbrb]

@andrevmatos @karlb Would this need changes to the Python client?

[karlb]

@christianbrb: If the python client is supposed to support ETHless operation then it does need changes. But it should be possible to add support for this in the contracts (so that the light client can use it) without breaking backwards compatibility by providing two separate functions (the old ones and the new ones that can delegated) for each operation. I can't tell how easy that would be without looking into this longer.

[fredo]

Would it be worth to look into something like GSN?

[palango]

UserDeposit.planWithdraw should allow to withdraw to a different account. This would make it possible to avoid some confusion in the light client, where the deposit is handled by the subkey account, but withdrawn deposits should be going back the the master key.