Reverting Register calls about go-perun HOT 5 CLOSED

The second possibility seems more interesting to me compared to the first one.

Because in the first case, the secondary flag has to be received at the top level API and should be propagated across different methods in the core of go-perun as well as the backend.

Whereas, in the second case, the user of the go-perun calls the wait function before Register/Settle as necessary. Also the secondary logic need to be included in any part of the go-perun (both core & backend). This also means the same objective achieved with lesser number of lines of code.

from go-perun.

The second possibility seems more interesting to me compared to the first one.

Im not sure if a waitNBlocks function instead of a secondary flag makes it less block chain agnostic.
In an instant-finality (but high TX fee) chain for example, this would complicate things.
What do you think @matthiasgeihs ?

from go-perun.

I don't see a big problem with having a transaction revert. If the transaction reverts because the channel has already been registered, that's ok, because the goal was to register the channel. The framework should just acknowledge that the channel has been registered, log the transaction error, but do not return the error to the user, as the goal of registering the channel has been fulfilled.

from go-perun.

I don't see a big problem with having a transaction revert.

Well it is not directly a "problem" because everything works as expected.
It is more of an optimization. We tried to build go-perun to be as gas efficient as possible.
This also means to prevent reverting transactions, hence why we introduced the secondary flag on the Settle call.

It is sure up for discussion on how far we should go here.

from go-perun.

We may consider this optimization at a later point when it becomes relevant in a concrete use case. Closing this issue for now.

from go-perun.