Date: Fri, 18 Feb 2022 16:06:39 +0000
To: Erik Aronesty <erik@q32.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <3YGc8zgpxTXfmj09vOFSHiGqubBn5Tb6PefbEje8vbSvcKt3wWlf2Ue1VCS33WFygsLq5Rvdv9FW8SCvoDqGNUVYT7gAa2z4NSdu5GHqkHc=@protonmail.com>
In-Reply-To: <CAJowKgKEAptvQnOSKc7W=FDtf6DRchaBUyx3QWeHbCN_89w2zQ@mail.gmail.com>
References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com>
 <CAJowKg+cK3ZjPCjcDK8v5qFA=uCHD7gcR8ymroXBFicU5jzY8Q@mail.gmail.com>
 <mSBTc8Bl5YIXe7LSX_fCNUYhd0wjepa_XhF6uhtwzF7s5h9-AEGWbkfrPA58nn431SjAqTkWEzd7YJ5mC0M7aZf-NmS5eDTN8LKEGQOFGcY=@protonmail.com>
 <CAJowKgKEAptvQnOSKc7W=FDtf6DRchaBUyx3QWeHbCN_89w2zQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to
	`OP_TAPLEAFUPDATEVERIFY`
Precedence: list

Good morning Erik,

> > As I understand your counterproposal, it would require publishing one t=
ransaction 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 w=
hich participants can be evicted, as you cannot predict the future and cann=
ot predict which partiicpants will go offline first.
>
> why would=C2=A0the ordering matter?=C2=A0 these are unordered pre commitm=
ents to move funds, right?=C2=A0 =C2=A0you agree post the one that represen=
ts "everyone that's offline"

Suppose `B` is offline first, then the remaining `A` `C` and `D` publish th=
e 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 e=
victs `C` as well, increasing combinatorial explosion.
And so on.

We *could* use multiple Tapleaves, of the form `<A> OP_CHECKSIG <BCD> OP_CH=
ECKSIG` for each participant.
Then the per-participant `<A>` signature is signed with `SIGHASH_SINGLE|SIG=
HASH_ANYONECANPAY` and is pre-signed, while the remainder is signed by `<BC=
D>` with default `SIGHASH_ALL`.
Then if one participant `B` is offline they can evict `B` and then the chan=
ge 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 b=
e used instead of `OP_CTV`=C2=A0
>
> i don't see how multiple users can securely share a channel (allowing mas=
sive 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