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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to