Can't recover from state loss after close/update and before settle

[andrevmatos]

If a pair of nodes call closeChannel/updateNonClosingBalanceProof, but then for any reason lose the state (namely, transferred_amount, locked_amount & locksroot of each side which produced the balance_hash of the close/update calls), the channel can never be settled, the funds stay forever locked in the contracts, and that pair of nodes can never have a new channel between them on the same TokeNetwork.
Of course we don't expect both nodes to lose state often, but nonetheless IMO this lockout scenario isn't desired in any situation, and maybe we can consider this a bug to be fixed.

[fredo]

@andrevmatos is your focus more on not being able to recover the funds or not being able to open a new channel within that pair?

• Discussion: Is the assumption still valid in the current raiden
• Is this a problem which we want to cover somehow?
• If yes, make a proposal how to solve this issue

[andrevmatos]

I think both, but on our testnet testings, what was more annoying was not being able to open a new channel within that pair.
The main point of this issue is that closing/updating with hashes, but requiring the actual values to settle, works as an unintended secrecy mechanism between closing and settling. Although settling is expected to be able to be performed by anyone, in practice, current method can only be called by someone who knows the amounts which composed both side's balanceHash.

[fredo]

In a discussion with andre he stated that this problem appears to be more relevant in the LC since it only stores the latest balance hashes. This issue is addressed in raiden-network/light-client#1607

[andrevmatos]

That LightClient issue isn't replacing this one. It was just a new issue we discovered about our LC implementation upon thinking more about it in the light of this one, but this is a different issue, which can affect not only the light-client.
It happens if both nodes lose state (e.g delete ~/.raiden) after close/update, but before settling a channel. Of course, it isn't expected for this to happen and surely not advisable, but IMO this doesn't excuse the contracts from holding the funds forever with no way to settle this, and also preventing the peers from connecting again on this token network.
This issue happen because on close/update, the nodes set a balanceHash, which is the hash of 3 fields: transferredAmount, lockedAmount and locksroot, on each other's side of the channel, and this works as a kind of secret. After settleTimeout, anyone can call settleChannel, but need to know the 6 values which generated the hash stored for both sides. If the state is lost and the peers can't know the values which composed the hashes, the SC don't allow anyone in the world, not even the peers accounts, to settle the channel, the funds stays locked forever on it and the peers can never reopen a channel on this network with each other again.

[karlb]

We could still allow a cooperative settle in that case. That would nicely solve the issue without introducing much additional code to write and test and even allows the nodes to decide on the fair split in this case in a flexible way.
I don't think we need to provide a way for totally uncooperative nodes to resolve this rare case. If the alternative is to not get any funds out, the nodes should be willing to cooperate somehow.

[palango]

other options

• allow to open concurrent channels (n closed, not settled, channels can coexist with one open channel), see Support opening a new channel during a settlement period #916
• allow for a default settlement (back to initial deposits) after waiting, e.g. 10 * settlement_timeout
• allow for full balance proofs at closing time
• don't fix it: addresses are cheap

For this current sprint, we want to come to a decision on the way forward.