ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2022-02-18 đź“ť Original message:Good morning Erik, > > As ...
đź“… Original date posted:2022-02-18
đź“ť Original message:Good morning Erik,
> > As I understand your counterproposal, it would require publishing one transaction per evicted participant.
>
> if you also pre-sign (N-2, N-3, etc), you can avoid this
It also increases the combinatorial explosion.
> > In addition, each participant has to store `N!` possible orderings in which participants can be evicted, as you cannot predict the future and cannot predict which partiicpants will go offline first.
>
> why would the ordering matter? these are unordered pre commitments to move funds, right?  you agree post the one that represents "everyone that's offline"
Suppose `B` is offline first, then the remaining `A` `C` and `D` publish the eviction transaction that evicts only `B`.
What happens if `C` then goes offline?
We need to prepare for that case (and other cases where the participants go offline at arbitrary orders) and pre-sign a spend from the `ACD` set and evicts `C` as well, increasing combinatorial explosion.
And so on.
We *could* use multiple Tapleaves, of the form `<A> OP_CHECKSIG <BCD> OP_CHECKSIG` for each participant.
Then the per-participant `<A>` signature is signed with `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` and is pre-signed, while the remainder is signed by `<BCD>` with default `SIGHASH_ALL`.
Then if one participant `B` is offline they can evict `B` and then the change is put into a new UTXO with a similar pre-signed scheme `<A> OP_CHECKSIG <CD> OP_CHECKSIG`.
This technique precludes pre-signing multiple evictions.
>
> > But yes, certainly that can work, just as pre-signed transactions can be used instead of `OP_CTV`Â
>
> i don't see how multiple users can securely share a channel (allowing massive additional scaling with lighting) without op_ctv
They can, they just pre-sign, like you pointed out.
The same technique works --- `OP_CTV` just avoids having ridiculous amounts of combinatorial explosion and just requires `O(log n)` per eviction.
Remember, this proposal can be used for channel factories just as well, as pointed out, so any objection to this proposal also applies to `OP_CTV`.
Regards,
ZmnSCPxj
đź“ť Original message:Good morning Erik,
> > As I understand your counterproposal, it would require publishing one transaction per evicted participant.
>
> if you also pre-sign (N-2, N-3, etc), you can avoid this
It also increases the combinatorial explosion.
> > In addition, each participant has to store `N!` possible orderings in which participants can be evicted, as you cannot predict the future and cannot predict which partiicpants will go offline first.
>
> why would the ordering matter? these are unordered pre commitments to move funds, right?  you agree post the one that represents "everyone that's offline"
Suppose `B` is offline first, then the remaining `A` `C` and `D` publish the eviction transaction that evicts only `B`.
What happens if `C` then goes offline?
We need to prepare for that case (and other cases where the participants go offline at arbitrary orders) and pre-sign a spend from the `ACD` set and evicts `C` as well, increasing combinatorial explosion.
And so on.
We *could* use multiple Tapleaves, of the form `<A> OP_CHECKSIG <BCD> OP_CHECKSIG` for each participant.
Then the per-participant `<A>` signature is signed with `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` and is pre-signed, while the remainder is signed by `<BCD>` with default `SIGHASH_ALL`.
Then if one participant `B` is offline they can evict `B` and then the change is put into a new UTXO with a similar pre-signed scheme `<A> OP_CHECKSIG <CD> OP_CHECKSIG`.
This technique precludes pre-signing multiple evictions.
>
> > But yes, certainly that can work, just as pre-signed transactions can be used instead of `OP_CTV`Â
>
> i don't see how multiple users can securely share a channel (allowing massive additional scaling with lighting) without op_ctv
They can, they just pre-sign, like you pointed out.
The same technique works --- `OP_CTV` just avoids having ridiculous amounts of combinatorial explosion and just requires `O(log n)` per eviction.
Remember, this proposal can be used for channel factories just as well, as pointed out, so any objection to this proposal also applies to `OP_CTV`.
Regards,
ZmnSCPxj