sdk/state: implement withdraw

[leighmcculloch]

Once the channel is open a participant may want to withdraw funds that belong to them without closing the entire channel. It is possible to top-up/deposit into the channel, it could be possible to withdraw without closing also.

[leighmcculloch]

I think we need to re-evaluate whether we want to tackle withdrawal functionality now as part of milestone 1a. Withdrawal feels like an important feature. I think it should be possible to withdraw funds from the channel without closing the channel. The SEP defines the process for doing so.

However, there are some costs to adding this feature:

The withdraw process requires storing additional state about what the valid sequence numbers are of the escrow account. This additional state permeates a few areas of the channel implementation and increases the complexity of the implementation.

Withdrawing, as we have defined it today, requires pausing use of the channel for the duration of the negotiation and the submission of the transaction to the network. Once the request to withdraw starts the channel must not perform any other operation, other than closing, until either the withdraw transaction is seen successful or unsuccessful on the network. This begs the question that if the channel must stop and wait for network state, what advantage does this offer over simply closing the channel? The advantages are: 1) privacy to what other state exists in the channel, 2) reduced fees since a close and open tx are expensive transactions in comparison to a withdraw transaction.

In many ways withdrawal is an optimization and so we could leave it out of this milestone and return to it in a future milestone once we have spent sometime validating what we have already.

The fact that withdrawing requires pausing the channel may also be a signal that it's something we should think about redesigning. It would be ideal if the withdrawal could be non-interactive.

I'd like to defer implementing withdraw and revisit the design at some point in the future, rather than implementing it now.

@acharb @nikhilsaraf @accordeiro @tomerweller Thoughts?

[leighmcculloch]

I'd like to defer implementing withdraw and revisit the design at some point in the future, rather than implementing it now.

@acharb @nikhilsaraf @accordeiro @tomerweller Thoughts?

I'm going to close this issue as no one has chimed in to champion keeping this feature. Please reopen if you think withdrawal is something we need.

[leighmcculloch]

Reopened but will keep out of a milestone.