path: root/0a/9f724b29654fab852a0ad2a5947fca9d9dd39d

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 866C2C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 15:50:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 67BAF611A6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 15:50:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level: 
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.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 vZBGo3OQddvl
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 15:50:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [IPv6:2a00:1450:4864:20::133])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 17FDA60B96
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 15:50:17 +0000 (UTC)
Received: by mail-lf1-x133.google.com with SMTP id i11so6280633lfu.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 18 Feb 2022 07:50:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=scjwpJixQr4JGVRjeUUhKMeCk9zhfHoKW7cwxd4F9nA=;
 b=oWKyL3rz+4CvcRhcy7HZHwS/D82ao0jIsrNf0hAj+IT6MXOPpSijJersetXoH3rXlP
 65BlVUogj1qEYRozLr2aU6XMZouyxCXS9xTqZj2wvbmufsq9Iyoo58Mx1wItCyx5npUA
 NK38nv+/0EEvNDpZSo2+faBT9KJFd+0/DzGVxKGla8+b7ZLS1W+4VzPrDebz9Oxp7ADI
 LVn8qQX2+ds3u5bkPM+9qZxKFIP9qGq0uk0lGLAnXaLHsti8uxgW2kceGUOG4sZYZc8j
 vYn9g52CJ7BPhqMl7kg/lBrMu/zB09zp5CYloKhkk05HNDOWsi07GdhieSwwG8MbsOFA
 ALvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=scjwpJixQr4JGVRjeUUhKMeCk9zhfHoKW7cwxd4F9nA=;
 b=qfsa0yqtF1dbjxZf16LG1c2akY8Zvfy20/eXkZAmhV9ey9PQRnq93sF10kReI5kgMX
 qHacfffDV+8uyv3Sn4eZMsCVet3uxLZbwsElq8/jL2BVgG6YMI/6gZfRxewQLHttUWFp
 uH7r9Kyv4TurKemoNZsTXdWp/6PbfHyt6X+guu5Y8h6riskEkWO5Oqq+PcbIdLtn7zIg
 4BwhdLKwnSBidSW/4Dd5SY2vxTVBIeOKi5HEwLOLTRpAR/QWJIeS0w0GwlPthEUgpAwc
 RLlE5hTieTghFb3o/kZRwWzhe309djEWeC2ZncJYShEyRjCaJn1tlSRt9PKZ5SfdKMNf
 cMMA==
X-Gm-Message-State: AOAM533opiwrqprhuQOyIB0txb1+PP8zyO5qD/q3JFIm2ImMQuMDNiyn
 HyEFPGnsOpDSxVAZpgp0upNq1sp2GraMdpE9efZfC6g=
X-Google-Smtp-Source: ABdhPJxet6QPfGuERYxUDqg7mH9ijkNOPaI8M1TLuWCrnCbjM2bl7lYml2ZaB47KZMaNxprwQq3H0pTLvKbITOhOpTQ=
X-Received: by 2002:a05:6512:1101:b0:443:7ead:191c with SMTP id
 l1-20020a056512110100b004437ead191cmr5985202lfg.188.1645199414657; Fri, 18
 Feb 2022 07:50:14 -0800 (PST)
MIME-Version: 1.0
References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com>
 <CAJowKg+cK3ZjPCjcDK8v5qFA=uCHD7gcR8ymroXBFicU5jzY8Q@mail.gmail.com>
 <mSBTc8Bl5YIXe7LSX_fCNUYhd0wjepa_XhF6uhtwzF7s5h9-AEGWbkfrPA58nn431SjAqTkWEzd7YJ5mC0M7aZf-NmS5eDTN8LKEGQOFGcY=@protonmail.com>
In-Reply-To: <mSBTc8Bl5YIXe7LSX_fCNUYhd0wjepa_XhF6uhtwzF7s5h9-AEGWbkfrPA58nn431SjAqTkWEzd7YJ5mC0M7aZf-NmS5eDTN8LKEGQOFGcY=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 18 Feb 2022 10:50:02 -0500
Message-ID: <CAJowKgKEAptvQnOSKc7W=FDtf6DRchaBUyx3QWeHbCN_89w2zQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000b206c205d84cd609"
X-Mailman-Approved-At: Fri, 18 Feb 2022 15:52:10 +0000
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`
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Feb 2022 15:50:18 -0000

--000000000000b206c205d84cd609
Content-Type: text/plain; charset="UTF-8"

> 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

> 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"

> 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


On Fri, Feb 18, 2022 at 9:48 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Erik,
>
> > hey, i read that whole thing, but i'm confused as to why it's necessary
> >
> > seems like N of N participants can pre-sign an on-chain transfer of
> funds for each participant to a new address that consists of (N-1) or (N-1)
> participants, of which each portion of the signature is encrypted for the
> same (N-1) participants
> >
> > then any (N-1) subset of participants can collude publish that
> transaction at any time to remove any other member from the pool
> >
> > all of the set up  (dkg for N-1), and transfer (encryption of partial
> sigs) is done offchain, and online with the participants that are online
>
>
> As I understand your counterproposal, it would require publishing one
> transaction per evicted participant.
> 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.
>
> Finally, please see also the other thread on lightning-dev:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
> In this thread, I point out that if we ever use channel factories, it
> would be best if we treat each channel as a 2-of-2 that participates in an
> overall N-of-N (i.e. the N in the outer channel factory is composed of
> 2-of-2).
> For example, instead of the channel factory being signed by participants
> `A`, `B`, `C`, `D`, instead the channel factory is signed by `AB`, `AC`,
> `AD`, `BC`, `BD`, `CD`, so that if e.g. participant B needs to be evicted,
> we can evict the signers `AB`, `BC`, and `BD`.
> This means that for the channel factory case, already the number of
> "participants" is quadratic on the number of *actual* participants, which
> greatly increases the number of transactions that need to be evicted in
> one-eviction-at-a-time schemes (which is how I understand your proposal) as
> well as increasing the `N!` number of signatures that need to be exchanged
> during setup.
>
>
> But yes, certainly that can work, just as pre-signed transactions can be
> used instead of `OP_CTV` or pretty much any non-`OP_CHECKMULTISIG` opcode,
> xref Smart Contracts Unchained.
>
> Regards,
> ZmnSCPxj
>

--000000000000b206c205d84cd609
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; As I understand your counterproposal, it would requir=
e publishing one transaction per evicted participant.<div><br></div><div>if=
 you also pre-sign (N-2, N-3, etc), you can avoid this<br><div><br>&gt; In =
addition, each participant has to store `N!` possible orderings in which pa=
rticipants can be evicted, as you cannot predict the future and cannot pred=
ict which partiicpants will go offline first.<br></div><div><br>why would=
=C2=A0the ordering matter?=C2=A0 these are unordered pre commitments to mov=
e funds, right?=C2=A0 =C2=A0you agree post the one that represents &quot;ev=
eryone that&#39;s offline&quot;</div><div><br>&gt; But yes, certainly that =
can work, just as pre-signed transactions can be used instead of `OP_CTV`=
=C2=A0<br><br>i don&#39;t see how multiple users can securely share a chann=
el (allowing massive additional scaling with lighting) without op_ctv<br><b=
r></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, Feb 18, 2022 at 9:48 AM ZmnSCPxj &lt;<a href=3D"mai=
lto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Erik,<br>
<br>
&gt; hey, i read that whole thing, but i&#39;m confused as to why it&#39;s =
necessary<br>
&gt;<br>
&gt; seems like N of N participants can pre-sign an on-chain transfer of fu=
nds for each participant to a new address that consists of (N-1) or (N-1) p=
articipants, of which each portion of the signature is encrypted for the sa=
me (N-1) participants<br>
&gt;<br>
&gt; then any (N-1) subset of participants can collude publish that transac=
tion at any time to remove any other member from=C2=A0the pool<br>
&gt;<br>
&gt; all of the set up=C2=A0 (dkg for N-1), and transfer (encryption of par=
tial sigs) is done offchain, and online with the participants=C2=A0that are=
 online<br>
<br>
<br>
As I understand your counterproposal, it would require publishing one trans=
action per evicted participant.<br>
In addition, each participant has to store `N!` possible orderings in which=
 participants can be evicted, as you cannot predict the future and cannot p=
redict which partiicpants will go offline first.<br>
<br>
Finally, please see also the other thread on lightning-dev: <a href=3D"http=
s://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.=
html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.or=
g/pipermail/lightning-dev/2022-February/003479.html</a><br>
In this thread, I point out that if we ever use channel factories, it would=
 be best if we treat each channel as a 2-of-2 that participates in an overa=
ll N-of-N (i.e. the N in the outer channel factory is composed of 2-of-2).<=
br>
For example, instead of the channel factory being signed by participants `A=
`, `B`, `C`, `D`, instead the channel factory is signed by `AB`, `AC`, `AD`=
, `BC`, `BD`, `CD`, so that if e.g. participant B needs to be evicted, we c=
an evict the signers `AB`, `BC`, and `BD`.<br>
This means that for the channel factory case, already the number of &quot;p=
articipants&quot; is quadratic on the number of *actual* participants, whic=
h greatly increases the number of transactions that need to be evicted in o=
ne-eviction-at-a-time schemes (which is how I understand your proposal) as =
well as increasing the `N!` number of signatures that need to be exchanged =
during setup.<br>
<br>
<br>
But yes, certainly that can work, just as pre-signed transactions can be us=
ed instead of `OP_CTV` or pretty much any non-`OP_CHECKMULTISIG` opcode, xr=
ef Smart Contracts Unchained.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000b206c205d84cd609--