Discussion: Making State Channels usable before min-depth

uwiger · August 27, 2020, 2:25pm

I am analysing Issue #3194, on how to make State Channels become usable earlier, ideally without sacrificing too much safety.

I have started writing down the analysis in a Github wiki page, and would appreciate comments on the different alternatives.

While investigating, I noticed that the minimum_depth_strategy option wasn’t ever officially documented. You will find a short description and some examples in the article.

dimitar.chain · August 31, 2020, 3:22pm

So first of all, thank you for documenting how the minimum_depth works. I am not sure if this had been documented so far, if it had - I am not aware of it

Then I don’t see why both parties should coordinate somehow their minimum_depth values: each channel participant takes care for their own benefit and this could sometimes mean that they require a different amount of confirmations. Once a participant’s FSM receives enough confirmations, it would inform the other participant’s FSM that it is ready to continue. Once the second one confirms - the channel is ready to go. The problem with having different minimum_depth values would be that the different FSMs would require a different amount of time to consider the confirmations to be enough. That actually is ok as the faster participant would wait for the slower one.

Regarding the link above, I see an extensive analysis of the minimum_depth. All of the approaches seem handy, except the first one (I guess it is for completeness). The thing is that all the three approaches are great but they solve different issues:

the modifiable minimum_depth per transaction makes more granular and pushes the responsibility to the client where it should be
the modifiable minimum_depth is no brainer, it should be changeable
the new request to the FSM is also no brainer as it empowers the client to make the decision when one feels secure enough to continue

So they are all connected and solving the similar problems. Possibly we want all of them, but if I were to pick just one, it would be the last one (and I will set a high default value at channel creation time…). In this case I would still miss the rest of the functionalities

uwiger · August 31, 2020, 3:48pm

Yes, I have been going for completeness.

I have a few more things I would like to add, then I want to break it down into separate issues that could be discussed and prioritized. I agree that there are some alternatives that could achieve at least part of what the initial problem formulation aims at.

uwiger · September 1, 2020, 9:50am

@vishwas_hypermine, do you have any comments or preference regarding how to proceed?

uwiger · September 2, 2020, 10:46am

While investigating this issue, I realized that the minimum depth handling in the FSMs is … uhm, surprising. I created an issue for it.

github.com/aeternity/aeternity

State Channels: minimum_depth setting defaults to undocumented/surprising value

opened 10:43AM - 02 Sep 20 UTC

closed 02:46PM - 28 Sep 21 UTC

uwiger

breaking/api

In the [documentation](https://github.com/aeternity/protocol/blob/master/node/ap…i/channels_api_usage.md#channel-establishing-parameters), the `minimum_depth` parameter is described simply as specifying the amount of (key-)blocks to wait after posting a transaction on-chain. A refined version of minimum_depth confirmation was implemented, but never officially documented. It is described in [this wiki page](https://github.com/aeternity/aeternity/wiki/Making-the-State-Channel-FSM-responsive-before-minimum-depth-confirmation#modifiable-minimum_depth-per-transaction). The somewhat surprising thing is that the way the options checking and interaction between `channel_open` and `channel_accept` messages, channels will _always_ end up choosing `minimum_depth_strategy => txfee`. The way it works is: * Minimum depth options are not checked in the initiator FSM * In the responder FSM, `minimum_depth_strategy` defaults to `txfee` if not provided, but `txfee` happens to also be the only allowed value * When the initiator receives the `channel_accept` message from the responder, it will use the responder's `minimum_depth_strategy` setting, if it doesn't have a valid setting for it already (there is only one valid setting). So whether or not `minimum_depth_strategy => txfee` is set explicitly, it _will_ become the active strategy. A possible fix might be to introduce something like `minimum_depth_strategy => plain`, meaning that `minimum_depth` will, in fact define the number of blocks to wait, as documented. This would mean updating the serialization format of the `channel_open` and `channel_accept` messages, which would break backwards compatibility. Another option would be to rewrite the default handling, so that channels will actually behave as documented unless `minimum_depth_strategy` is explicitly set. Unfortunately, many people pay more attention to how things actually work than what the documentation says, so this could be seen as breaking existing code as well. One should probably do both of the above, but changing the serialization format _will_ break some interactions with channels running on nodes having older software.