Alejandro Ranchal Pedrosa [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-20 📝 Original message: Hi ZmnSCPxj, I also ...
📅 Original date posted:2019-04-20
📝 Original message:
Hi ZmnSCPxj,
I also thought about the possibility of using 'SIGHASH_NOINPUT', it
certainly offers a functionality very similar to the one I suggest in
the paper.
The problem with 'SIGHASH_NOINPUT' as it is now is that, if I am not
mistaken, in the example you are showing, seems like A,D and C can
unilaterally decide to include a new participant, F. Seems to me like
this can affect the no-lock property of offchain layers, since they
might require F to release the funds in the mainchain.
Certainly, with some variants to SIGHASH_NOINPUT this solution can be
achieved. Actually, this is in some way what I propose in the Lightning
Factories paper. Adding a non-interactive aggregate signature scheme is
just going one step further with an optimization to save space, the same
way Schnorr-based signatures schemes for aggregation are proposed in
Channel Factories. But with minor variants (that are listed in the
paper), a SIGHASH_NOINPUT would work like a charm.
Best,
Alejandro.
On 17/04/2019 13:39, ZmnSCPxj wrote:
> 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.
>
> Regards,
> ZmnSCPxj
--
Alejandro Ranchal Pedrosa
📝 Original message:
Hi ZmnSCPxj,
I also thought about the possibility of using 'SIGHASH_NOINPUT', it
certainly offers a functionality very similar to the one I suggest in
the paper.
The problem with 'SIGHASH_NOINPUT' as it is now is that, if I am not
mistaken, in the example you are showing, seems like A,D and C can
unilaterally decide to include a new participant, F. Seems to me like
this can affect the no-lock property of offchain layers, since they
might require F to release the funds in the mainchain.
Certainly, with some variants to SIGHASH_NOINPUT this solution can be
achieved. Actually, this is in some way what I propose in the Lightning
Factories paper. Adding a non-interactive aggregate signature scheme is
just going one step further with an optimization to save space, the same
way Schnorr-based signatures schemes for aggregation are proposed in
Channel Factories. But with minor variants (that are listed in the
paper), a SIGHASH_NOINPUT would work like a charm.
Best,
Alejandro.
On 17/04/2019 13:39, ZmnSCPxj wrote:
> 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.
>
> Regards,
> ZmnSCPxj
--
Alejandro Ranchal Pedrosa