[Lightning-dev] Stale Factory (and channel) problem

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed Apr 17 03:39:09 UTC 2019

Good morning Alejandro and list,

Let me characterize the problem in detail.

* Stale offchain system is the issue where one participant of a multiparticipant offchain system sends a signature that advances the protocol, but is unable to receive further signatures from one or more of the other participants to continue the protocol.
* Often, such a stall in the protocol requires some timeout and a backoff path, aborting the protocol and performing some corrective action onchain.
* More participants means more chances of this kind of stale offchain system disruption.

* For two-participant offchain systems ("payment channels"), this disruption is indistinguishable from the other participant going offline.
* For payment channels, the other participant going offline implies that future updates of the channel will not occur, thus it is always possible for participants to insist on redoing the signature exchange before performing further updates.
  * Thus, for payment channels, this issue can be fixed by allowing the exchange of signatures (including those you believe to have sent previously) of the most recent state upon re-establishing a communication channel.
  * BOLT already requires this.

* For multiparticipant offchain systems that host other offchain systems ("channel factories"), this disruption is also indistinguishable from one of the participants going offline.
* For channel factories, the remaining participants might wish to continue participating in hosted offchain systems ("on-factory channels") that do not involve the dropped participant.
* However, it is unknown if the dropped participant is able to construct the new state or not.
  * Thus it is ambiguous if on-factory channels should be rooted from the old state or the new state.


A thought comes to mind: would `SIGHASH_NOINPUT` help?
On-factory channels not affected by a channel reorganization operation at the factory level can continue to operate, by use of `SIGHASH_NOINPUT`.

For instance, suppose the current factory state is the channels: (A, B) 1; (B, C) 1; (A, D) 1; (C, D) 1
Suppose A, C, and D propose a reorganization to the new state: (A, B) 1; (B, C) 1; (A, C) 0.5; (C, D) 1.5

If channel states use `SIGHASH_NOINPUT` in signatures, then (A, B) and (B, C) channels can be trivially re-rooted in both the old or the new factory state,
At the same time, (A, D) 1 and (C, D) 1 are both closed until the new state is completely signed, so their continued operation is stopped.
And the channels (A, C) 0.5 and (C, D) 1.5 are not yet opened until the new state is completely signed, so their operation cannot be begun.

This allows unaffected channels to continue operation even if a factory-level operation is in an indterminate state.


More information about the Lightning-dev mailing list