SC disconnection and leave

[dave]

I’m calling leave(…) on a SC but it seems channel is kind of disconnected on beforehand.

• Can you confirm this?
• Is there a way to retrieve latest SC state ?

client Saving...:  undefined
Cannot leave:Error: Unexpected message received:

{"jsonrpc":"2.0","method":"channels.info","params":{"channel_id":"ch_h79pSyHcphzg4P9V87KZLQ2Hnb73UH52fN6xXdUrVWCmAjuYY","data":{"event":"timeout"}},"version":1}
[Nest] 10383   - 09/03/2019, 7:29 PM   [customer] ak_Zig4hkSq8Q9s|[DIED]
[Nest] 10383   - 09/03/2019, 7:29 PM   [customer] ak_Zig4hkSq8Q9s|[DISCONNECTED]

Another, related question:

• what would be the problem if both peers try to re-establish a channel with a non-final but mutually-agreed state? should they be able to restablish? (at the moment they can’t, it seems the node expects they to have the last state it had).

[dimitar.chain]

@dave
I can not help you with the leave function as I am not familiar with the JS SDK but here is what the node supports for you:

• getters for different views of the channel state:
  • you can request specific balances
  • you can get a proof of inclusion for accounts and contracts. This PoI will have the very same root hash as the latest co-authenticated channel transaction
  • you can dry run a contract or fetch a contract call if it is not yet prunned
• you can also get the whole off-chain state tree. I see this is documented just in one of the protocol files describing the node protocol. Improving the docs is tracked as SC protocol - describe method channels.get.offchain_state.

Regarding the question for re-establishing a channel with another different state that is not the very latest one according to the node - it makes perfect sense, I neither see a reason to forbid it, nor I see how it could be enforced in any way. From a tech perspective - we want participants to be able to take their state from Node1, migrate it to Node2 and re-establish from Node2. With this in mind, Node2 has no notion if the state that it received was really the very latest one or rather a mutually agreed one. From a greater perspective - this is not a decision for the node to make in the first place - our priority is for participants to be in full control of their data and to make educated decisions about it. It is just that we haven’t even started working on migration of state from Node1 to Node2 and this will not be implemented for the Lima hard fork. To answer your question:

what would be the problem if both peers try to re-establish a channel with a non-final but mutually-agreed state?

Only problem being it is not implemented yet

[dave]

We switched to use:

channel.on('stateChanged', (state) => {
  offchainTx = state
  existingChannelId = initiatorCh.id()
})

to capture the state change as it is produced. This way we’ll always have the state updated, rather than if we are calling channel.state() on and on…

Thanks for the answer!!!