path: root/c0/a995da51d32e8a30a0c7a3284c849d30de369a

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BC27EC001A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 17:00:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id A42D281BA9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 17:00:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wvERoP_uPDS7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 17:00:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [IPv6:2a00:1450:4864:20::62f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 36D4981B71
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 17:00:12 +0000 (UTC)
Received: by mail-ej1-x62f.google.com with SMTP id p14so20356092ejf.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 09:00:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=r3/qyUFyN6aNwQ1Y6/ptSgJgW27wPaNqlGio6n/aY/Q=;
 b=ejCoLw0gejrQ5qXPk5Y3Xe75+qCJy2Hqkq48tlTAlLGgShT3KLrUty2jhZytu60sxh
 M2DMqz0do/dA87yDVVx6caPqcfn2R0K3rKqZ/tGxj/usKO1fBUiXbaA8/u5sYNcqJ2e9
 XQQ6UyPc/RvBKs6LcyCuuaYvkjpy8MD2102Zfqa6QdZvREY9RdT3cgkG3MPGNOydAZUx
 EPEzKLf7lnQUSUXjHCe9a2+SymXRsARHmo5bFuVnRJPGk2LA6Ej0lDsrJQJpWLRyWI07
 PqCE0MbpnmSBIAkNuIB5IaLZBf+OYhA3GZF2sSkZpbVHHiHtb99Kebe4eRQuPTNZmr1+
 8h5Q==
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;
 bh=r3/qyUFyN6aNwQ1Y6/ptSgJgW27wPaNqlGio6n/aY/Q=;
 b=EUAQ8blhQpWy0WhqBmRt/8QFKi+fckKDNhRuhV43kHT3dWOzeAUtxLa2H3hmRUUucZ
 IPt46kBbcKw14DLiJ9XmpQfgMwoA8s544MThDzFABUOt6TUY5VXi8e+WeutqoToIghOh
 WGKM8H7AFKlhfcEogHcnrcFkp8KkvSEhIlj/IBae/3bk4AHdFsP/WRbFuM94ZDwZk4yn
 osp4gMG9yJrADeLQmIkxAF3TmWudan+rKRBe8K9rHecgBSbNrPCiuP4BkQsgni2Qggmx
 Pc+yPqP3vA4rrVYrKqy+VTP9cW5bqWXoWOd20vGPBqp0r1A51rJLSZEjmAbpPli4Vj69
 QVpw==
X-Gm-Message-State: AOAM533AduquJ96qA23zQvYIE2gJ1RppB3Ce54PCTWFvG0bl8SWUl9Rs
 Fo07RptxK0ST+A08ooUjBm5mbQoe8t75Preq+1cHDDmx6Os=
X-Google-Smtp-Source: ABdhPJxXhPPfhDbOEbPdNNb5jghyRefTuqTVC+hOZXwXec7mupVx1I0e9BTroINRkqqXAi8b+A9MEYPRTuhygzFjw9c=
X-Received: by 2002:a17:906:974e:b0:6bb:4f90:a6ae with SMTP id
 o14-20020a170906974e00b006bb4f90a6aemr12898215ejy.452.1645981210193; Sun, 27
 Feb 2022 09:00:10 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
 <i710HUIxNHIqCNhkh07dzlShyDp9ZkoEokw9ZBezCFvsk05ZUy5fXK1xx_IQifLh4f3RYb8FJM_MFm7hAaQFaUM3Jy3E8QhfSzkaogAu1Gs=@protonmail.com>
 <20220224065305.GB1965@erisian.com.au>
 <bQvm5sSOMGRKR2udDFTNCJlOv_2vuIjkkBsoYqi4463y8ZjFDY4kxVvJEz7yv0GfxbyrMo-eOhOnEnd6sKPrWSk6PXn8KNerRlWsiGsWZRU=@protonmail.com>
 <CAGpPWDaVN4iAzfDKEQs2hmoQOHtToyPao1FgDCsMTJvt7pbq5g@mail.gmail.com>
 <fV9nkjr6K9fQWJWXtO4b3uZGzpHvDNdQa89X73yUB2YVsvuNVPDqsJln88pEef1fzHsui-qnneXdmYsO7CDibxMrm9PBDOO0Ls8RV1Bx1BI=@protonmail.com>
 <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com>
 <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
 <erNX61VSwzTcxedBOPn50Qh5rqidnUXBcqOXDz9i13U7Ac-knnYzdr3bMYT1ATyUE37OlEgRirv8BdD4EpG8vj0pNdd2p8x8gkoKvhTh0J8=@protonmail.com>
In-Reply-To: <erNX61VSwzTcxedBOPn50Qh5rqidnUXBcqOXDz9i13U7Ac-knnYzdr3bMYT1ATyUE37OlEgRirv8BdD4EpG8vj0pNdd2p8x8gkoKvhTh0J8=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 27 Feb 2022 10:59:54 -0600
Message-ID: <CAGpPWDZ6=ww+NbKGNgUPOSFkwMf1i3nAmwVOy+27i0RUYF4eLQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000057330105d902dd31"
X-Mailman-Approved-At: Sun, 27 Feb 2022 17:06:47 +0000
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
 or the absence thereof,
 was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
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: Sun, 27 Feb 2022 17:00:13 -0000

--00000000000057330105d902dd31
Content-Type: text/plain; charset="UTF-8"

@Paul
> I think largeblock sidechains should be reconsidered:
> * They are not a blocksize increase.

This is short sighted. They would absolutely be a blocksize increase for
those following a large block sidechain. While sure, it wouldn't affect
bitcoin users who don't follow that sidechain, its misleading to call it
"not a blocksize increase" for everyone.

> * They allow users to be different. Some can pay more (for more decentralization), some less (for less decentralization).

> gambling the entire future of BTC, on the premise that strong decentralization will always be needed at all points in time.

Decentralization isn't just something where more is more valuable and
less is less valuable. Decentralization is either enough to stop a
class of attack or its not. Its pretty binary. If the decentralization
is not enough, it would be a pretty huge catastrophe for those
involved. Its pretty clear that making the blocksize eg 10 times
larger is a poor design choice. So advocating for such a thing on a
sidechain is just as bad as advocating for it on an altcoin.

Even if people only put a couple satoshis in such a sidechain at a
time, and don't feel the loss very much, the *world* would feel the
loss. Eg if everyone had $1 in such a system, and someone stole it
all, it would be a theft of billions of dollars. The fact that no
individual would feel much pain would make it not much less harmful to
society.

> We can learn from past mistakes -- when a new largeblock sidechain is needed, we can make a new one from scratch, using everything we know.

If there's some design principles that *allow* for safely increasing the
blocksize substantially like that, then I'd advocate for it in bitcoin. But
the goal of sidechains should not be "shoot from the hip and after everyone
on that sidechain gets burned we'll have learned valuable lessons". That's
not how engineering works. That's akin to wreckless human experimentation.



On Sun, Feb 27, 2022 at 1:25 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning again Paul,
>
> > With sidechains, changing the ownership set requires that the sidechain
> produce a block.
> > That block requires a 32-byte commitment in the coinbase.
> > What is more, if any transfers occur on the sidechain, they cannot be
> real without a sidechain block, that has to be committed on the mainchain.
>
> The above holds if the mainchain miners also act as sidechain validators.
> If they are somehow separate (i.e. blind merge mining), then the
> `OP_BRIBE` transaction needed is also another transaction.
> Assuming the sidechain validator is using Taproot as well, it needs the
> 32+1 txin, a 64-byte signature, a 32-byte copy of the sidechain commitment
> that the miner is being bribed to put in the coinbase, and a txout for any
> change the sidechain validator has.
>
> This is somewhat worse than the case for channel factories, even if you
> assume that every block, at least one channel factory has to do an
> onboarding event.
>
> > Thus, while changing the membership set of a channel factory is more
> expensive (it requires a pointer to the previous txout, a 64-byte Taproot
> signature, and a new Taproot address), continuous operation does not
> publish any data at all.
> > While in sidehchains, continuous operation and ordinary payments
> requires ideally one commitment of 32 bytes per mainchain block.
> > Continuous operation of the sidechain then implies a constant stream of
> 32-byte commitments, whereas continuous operation of a channel factory, in
> the absence of membership set changes, has 0 bytes per block being
> published.
> >
> > We assume that onboarding new members is much rarer than existing
> members actually paying each other in an actual economy (after the first
> burst of onboarding, new members will only arise in proportion to the birth
> rate, but typical economic transactions occur much more often), so
> optimizing for the continuous operation seems a better tradeoff.
>
> Perhaps more illustratively, with channel factories, different layers have
> different actions they can do, and the only one that needs to be broadcast
> widely are actions on the onchain layer:
>
> * Onchain: onboarding / deboarding
> * Channel Factory: channel topology change
> * Channel: payments
>
> This is in contrast with merge-mined Sidechains, where *all* activity
> requires a commitment on the mainchain:
>
> * Onchain: onboarding / deboarding, payments
>
> While it is true that all onboarding, deboarding, and payments are
> summarized in a single commitment, notice how in LN-with-channel-factories,
> all onboarding / deboarding is *also* summarized, but payments *have no
> onchain impact*, at all.
>
> Without channel factories, LN is only:
>
> * Onchain: onboarding / deboarding, channel topology change
> * Channel: payments
>
> So even without channel factories there is already a win, although again,
> due to the large numbers of channels we need, a channel factory in practice
> will be needed to get significantly better scaling.
>
>
> Finally, in practice with Drivechains, starting a new sidechain requires
> implicit permission from the miners.
> With LN, new channels and channel factories do not require any permission,
> as they are indistinguishable from ordinary transactions.
> (the gossip system does leak that a particular UTXO is a particular
> published channel, but gossip triggers after deep confirmation, at which
> point it would be too late for miners to censor the channel opening.
> The miners can censor channel closure for published channels, admittedly,
> but at least you can *start* a new channel without being censored, which
> you cannot do with Drivechain sidechains.)
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">@Paul<br><div><span style=3D"white-space:pre-wrap">&gt; I =
think </span>largeblock<span style=3D"white-space:pre-wrap"> </span>sidecha=
ins<span style=3D"white-space:pre-wrap"> should be reconsidered:</span></di=
v><div><span style=3D"white-space:pre-wrap">&gt; * They are not a blocksize=
 increase.</span></div><div><br></div><div><span style=3D"white-space:pre-w=
rap">This is short sighted. They would absolutely be a blocksize increase f=
or those following a large block sidechain. While sure, it wouldn&#39;t aff=
ect bitcoin users who don&#39;t follow that sidechain, its misleading to ca=
ll it &quot;not a blocksize increase&quot; for everyone. </span></div><div>=
<pre style=3D"white-space:pre-wrap"><span style=3D"font-family:Arial,Helvet=
ica,sans-serif">&gt; * They allow users to be different. Some can pay more =
(for more decentralization), some less (for less decentralization).</span>
</pre><pre style=3D"white-space:pre-wrap"><span style=3D"font-family:Arial,=
Helvetica,sans-serif">&gt; </span>gambling the entire future of BTC, on the=
 premise that strong decentralization will always be needed at all points i=
n time.</pre><pre style=3D"white-space:pre-wrap"><span style=3D"font-family=
:Arial,Helvetica,sans-serif">Decentralization isn&#39;t just something wher=
e more is more valuable and less is less valuable. Decentralization is eith=
er enough to stop a class of attack or its not. Its pretty binary. If the d=
ecentralization is not enough, it would be a pretty huge catastrophe for th=
ose involved. Its pretty clear that making the blocksize eg 10 times larger=
 is a poor design choice. So advocating for such a thing on a sidechain is =
just as bad as advocating for it on an altcoin. </span></pre><pre style=3D"=
white-space:pre-wrap"><span style=3D"font-family:Arial,Helvetica,sans-serif=
">Even if people only put a couple satoshis in such a sidechain at a time, =
and don&#39;t feel the loss very much, the *world* would feel the loss. Eg =
if everyone had $1 in such a system, and someone stole it all, it would be =
a theft of billions of dollars. The fact that no individual would feel much=
 pain would make it not much less harmful to society. </span></pre><pre sty=
le=3D"white-space:pre-wrap"><span style=3D"font-family:Arial,Helvetica,sans=
-serif">&gt; </span>We can learn from past mistakes -- when a new largebloc=
k sidechain is needed, we can make a new one from scratch, using everything=
 we know.</pre>If there&#39;s some design principles that *allow* for safel=
y increasing the blocksize substantially like that, then I&#39;d advocate f=
or it in bitcoin. But the goal of sidechains should not be &quot;shoot from=
 the hip and after everyone on that sidechain gets burned we&#39;ll have le=
arned valuable lessons&quot;. That&#39;s not how engineering works. That&#3=
9;s akin to wreckless human experimentation.</div><div><br></div><div><pre =
style=3D"white-space:pre-wrap"><br></pre></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 27, 2022 at 1:25=
 AM ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org">bitcoin-dev@lists.linuxfoundation.org</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 again Paul=
,<br>
<br>
&gt; With sidechains, changing the ownership set requires that the sidechai=
n produce a block.<br>
&gt; That block requires a 32-byte commitment in the coinbase.<br>
&gt; What is more, if any transfers occur on the sidechain, they cannot be =
real without a sidechain block, that has to be committed on the mainchain.<=
br>
<br>
The above holds if the mainchain miners also act as sidechain validators.<b=
r>
If they are somehow separate (i.e. blind merge mining), then the `OP_BRIBE`=
 transaction needed is also another transaction.<br>
Assuming the sidechain validator is using Taproot as well, it needs the 32+=
1 txin, a 64-byte signature, a 32-byte copy of the sidechain commitment tha=
t the miner is being bribed to put in the coinbase, and a txout for any cha=
nge the sidechain validator has.<br>
<br>
This is somewhat worse than the case for channel factories, even if you ass=
ume that every block, at least one channel factory has to do an onboarding =
event.<br>
<br>
&gt; Thus, while changing the membership set of a channel factory is more e=
xpensive (it requires a pointer to the previous txout, a 64-byte Taproot si=
gnature, and a new Taproot address), continuous operation does not publish =
any data at all.<br>
&gt; While in sidehchains, continuous operation and ordinary payments requi=
res ideally one commitment of 32 bytes per mainchain block.<br>
&gt; Continuous operation of the sidechain then implies a constant stream o=
f 32-byte commitments, whereas continuous operation of a channel factory, i=
n the absence of membership set changes, has 0 bytes per block being publis=
hed.<br>
&gt;<br>
&gt; We assume that onboarding new members is much rarer than existing memb=
ers actually paying each other in an actual economy (after the first burst =
of onboarding, new members will only arise in proportion to the birth rate,=
 but typical economic transactions occur much more often), so optimizing fo=
r the continuous operation seems a better tradeoff.<br>
<br>
Perhaps more illustratively, with channel factories, different layers have =
different actions they can do, and the only one that needs to be broadcast =
widely are actions on the onchain layer:<br>
<br>
* Onchain: onboarding / deboarding<br>
* Channel Factory: channel topology change<br>
* Channel: payments<br>
<br>
This is in contrast with merge-mined Sidechains, where *all* activity requi=
res a commitment on the mainchain:<br>
<br>
* Onchain: onboarding / deboarding, payments<br>
<br>
While it is true that all onboarding, deboarding, and payments are summariz=
ed in a single commitment, notice how in LN-with-channel-factories, all onb=
oarding / deboarding is *also* summarized, but payments *have no onchain im=
pact*, at all.<br>
<br>
Without channel factories, LN is only:<br>
<br>
* Onchain: onboarding / deboarding, channel topology change<br>
* Channel: payments<br>
<br>
So even without channel factories there is already a win, although again, d=
ue to the large numbers of channels we need, a channel factory in practice =
will be needed to get significantly better scaling.<br>
<br>
<br>
Finally, in practice with Drivechains, starting a new sidechain requires im=
plicit permission from the miners.<br>
With LN, new channels and channel factories do not require any permission, =
as they are indistinguishable from ordinary transactions.<br>
(the gossip system does leak that a particular UTXO is a particular publish=
ed channel, but gossip triggers after deep confirmation, at which point it =
would be too late for miners to censor the channel opening.<br>
The miners can censor channel closure for published channels, admittedly, b=
ut at least you can *start* a new channel without being censored, which you=
 cannot do with Drivechain sidechains.)<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000057330105d902dd31--