CooperativeSettle protocol leveraging withdraw messages

[andrevmatos]

raiden-network/raiden-contracts#1474 introduced a method for cooperative settle which uses two WithdrawConfirmations (one for each side) which further constraints in order to settle the channel instantly.

• withdraw requests must be for the whole capacity of the channel
• there must be no pending locks on either side

For this, we don't need to implement a new set of messages, but instead can do only with the normal withdraw requests, as long as the above conditions are true. To do so, we propose a simple new optional field to WithdrawRequest, coop_settle, to be a boolean and true when this withdraw request is intended to be used for a cooperative settle.
The whole message and signature works exactly the same as the normal withdraws, with the difference that the clients should not (although they could) send a tx to withdraw when receiving WithdrawConfirmation. Instead, the requestee's side, besides signing and sending it, if willing to comply and the conditions hold, just send a request of their own whole balance as well. Requester's will wait for it, and then perform the coopSettle when receiving the valid request on their side.

So, in resume:

• when willing to coop-settle, we send a WithdrawRequest with property coop_settle: true with our whole balance
• partner, when receiving it, will confirm it as usual and also initiate a WithdrawRequest with their whole balance (if no pending locks are present on neither side) and may also set coop_settle: false on it, but requester shouldn't mind it, as long a the confirmation is valid.
• when we receive their WithdrawRequest, we can confirm it as usual, but now, having both confirmations, we can just coop-settle
• partner may just be sure to not withdraw nor coop-settle on their side upon WithdrawConfirmations, since this was triggered by the other end
• the withdraw requests will "lock" the whole balance anyway while they're pending, preventing any new transfer to go through meanwhile
• if for any reason the coop-settle can't be performed, the requests can expire as usual and the channel become usable after that, so no need for further safetyguards beyond those already implemented for withdraws

[ezdac]

Regarding backwards compatibility for nodes not knowing about the coop-settle and not being aware of the new schema:

• in pyRaiden, if a coop_settle was present in the WithdrawRequest - it would be silently dropped upon decoding.
• The node would answer with a WithdrawConfirmation if the conditions are valid.

How would the CoopSettle-initiating node react? Would you still withdraw and change the intended coop-settle action to a withdraw action with the full balance? Or would you recognise the node can't handle the coop-settle and just let it expire?
(Theoretically the withdraw is already "valid": the other node could also do the withdraw, since it has the initiating nodes' signature)

I think it makes sense to react with a non-coop settle process from the initiators side, since settling the channel is what was intended by the user.
The problem is that this is more expensive. We could think about doing this silently and trying a CoopSettle whenever a user calls the channel-close endpoint, and if it fails the normal close/settle process is done.

[andrevmatos]

How would the CoopSettle-initiating node react? Would you still withdraw and change the intended coop-settle action to a withdraw action with the full balance? Or would you recognise the node can't handle the coop-settle and just let it expire?

This is up to each implementation, no need to have this behavior enforced/spec'd in the protocol, but I'd say we shouldn't initiate the withdraw in this case (even if we could). Instead, the user could actively try for an explicit withdraw, and if the amount was the maximum, we could/should instead detect there's a pending valid confirmation and re-use it for the withdraw.

I think it makes sense to react with a non-coop settle process from the initiators side, since settling the channel is what was intended by the user.
The problem is that this is more expensive. We could think about doing this silently and trying a CoopSettle whenever a user calls the channel-close endpoint, and if it fails the normal close/settle process is done.

Yes, I think it may be useful to try this by default if possible in the channel-close method call, and fallback to non-coop close if it fails or if we can't receive the other withdraw request in a given timeout. We may just need to ensure the clients are fine with initiate closing when withdraw is pending

[palango]

For this, we don't need to implement a new set of messages, but instead can do only with the normal withdraw requests, as long as the above conditions are true.

Sure, we can do this, but at the expense of way more complexity in the existing withdraw protocol.

I'd still argue that adding a couple of new messages is a favorable trade-off to complicating the existing withdraw.

[ezdac]

Documentation of this for the spec is given in #346

[ezdac]

Closing this since the functionality has been implemented by both clients and documented in the spec.