Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3B285C000B for ; Fri, 18 Feb 2022 16:06:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 224B260B96 for ; Fri, 18 Feb 2022 16:06:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6IsMq4vR9U4 for ; Fri, 18 Feb 2022 16:06:51 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp3.osuosl.org (Postfix) with ESMTPS id F14F160B54 for ; Fri, 18 Feb 2022 16:06:50 +0000 (UTC) Date: Fri, 18 Feb 2022 16:06:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1645200407; bh=w3zZfPBV32gADgUsiRR+VtkMT5aj9mHcLyF/b71TWtg=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=tZ0HCH8cgSKcm6AQkv1K0hNyjBPDm8VeBhe2jjX0SzBQNYYQK5ZhxUqDcFJZZZDiF 4j5QDUvhhmdVuR8a36J7rgujPs02e+szQEXGyFuWurcGEZH5FnMih3sysfm+hPve9c Ecg0uFeb1K3fj2NFb9tV/+nTMg5uDeCK0CS6qrvmmeI1BMOGvJUgIkzGzPALNvciXk wZZIC6qPZtWa8q5vOiy2JoLXSTFEz5EhNrrVx+lvfeVvRMLty2nGwg1x9NWpmOhr0k siPe8QcrjA9/4YePDD2OIx2UvOFi6ZDdkUjNYD9brfORCmtS2blkcQ52tPQw6bqgYD G1hXHqr7zkHPA== To: Erik Aronesty From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <3YGc8zgpxTXfmj09vOFSHiGqubBn5Tb6PefbEje8vbSvcKt3wWlf2Ue1VCS33WFygsLq5Rvdv9FW8SCvoDqGNUVYT7gAa2z4NSdu5GHqkHc=@protonmail.com> In-Reply-To: References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion , Anthony Towns Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY` X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2022 16:06:52 -0000 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 ` OP_CHECKSIG OP_CH= ECKSIG` for each participant. Then the per-participant `` signature is signed with `SIGHASH_SINGLE|SIG= HASH_ANYONECANPAY` and is pre-signed, while the remainder is signed by `` 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 ` OP_CHECKSIG= 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