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 

* 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.

Lightning-dev mailing list

Reply via email to