path: root/e4/a2ea65955dd7836ce09aa1fec56658967185c8

Return-Path: <prayank@tutanota.de>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BEAA7C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Sep 2021 09:47:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id A65C161490
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Sep 2021 09:47:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 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=tutanota.de
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 be0-9csZocjg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Sep 2021 09:47:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 83A6B605E7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Sep 2021 09:47:48 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
 by w1.tutanota.de (Postfix) with ESMTP id B1D9CFA0564;
 Fri,  3 Sep 2021 09:47:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1630662465; 
 s=s1; d=tutanota.de;
 h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;
 bh=d5kfYLCiQ0pfUXyxct8Vjr3rWxJuuTtJoK12c5ad+qI=;
 b=WZ0nsXWql+o8gU6enY2TDpJVfJ8MzuMDHOANsNE5k44Zrz22GFXm2mttpw2a6Yvm
 tHe5E9WtKpcCDUPyr4eRzXxz0S2zeLiAfFS4pf6sZxAfM2h+Qm0N0Rq3ZnsoNQmL09w
 983P30tl9tNyggwqhkh2Gh6MuwO2Qh+lTHB1Wfgf+Qxv6YpTlcMcYb4FyK8HeyzXo4G
 /Gjxe+jChNKNrpe2AuWrvOBQaqyLFklGKPWQLQATfNHntrsusUNv+oee5VKaqb/hGvG
 O42eVx7Pl91Cfxb0BYOd2d/Zy6MPBWLXf97afs44KhyzfWdPsB4jbfCy12NbbHSiDZv
 h9pK/ZkBNg==
Date: Fri, 3 Sep 2021 11:47:45 +0200 (CEST)
From: Prayank <prayank@tutanota.de>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Mif2dMR--3-2@tutanota.de>
In-Reply-To: <3dyAATLXbsE7WBzpVIc0s4sRkSFhR_5NN04uUgx3o9LH48IKR6EHL3V45PfpRM96yxHXdsjd7WC7MGuPlBw7MRpCkpXRsB-WI7i3-Nr13Ew=@protonmail.com>
References: <MibU_fn--3-2@tutanota.de>
 <3dyAATLXbsE7WBzpVIc0s4sRkSFhR_5NN04uUgx3o9LH48IKR6EHL3V45PfpRM96yxHXdsjd7WC7MGuPlBw7MRpCkpXRsB-WI7i3-Nr13Ew=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_69236_1936841571.1630662465710"
X-Mailman-Approved-At: Fri, 03 Sep 2021 10:09:40 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain: BIP 300 and 301
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, 03 Sep 2021 09:47:50 -0000

------=_Part_69236_1936841571.1630662465710
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good morning=C2=A0ZmnSCPxj,

Thanks for sharing all the details. One thing that I am not sure about:

>=C2=A0* We already ***know*** that blockchains cannot scale
> * Your plan for scaling is to make ***more*** blockchains?

Scaling Bitcoin can be different from scaling Bitcoin sidechains. You can e=
xperiment with lot of things on sidechains to scale which isn't true for Bi=
tcoin. Most important thing is requirements for running a node differ. Its =
easy to run a node for LN, Liquid and Rootstock right now. Will it remain t=
he same? I am not sure.

LND:=C2=A0https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.=
md

Liquid:=C2=A0https://help.blockstream.com/hc/en-us/articles/900002026026-Ho=
w-do-I-set-up-a-Liquid-node-

Rootstock:=C2=A0https://developers.rsk.co/rsk/node/install/

>=C2=A0More to the point: what are sidechains **for**?

Smart contracts are possible on Bitcoin but with limited functionality so l=
ot of applications are not possible using Bitcoin (Layer1). Some of these d=
on't even make sense on Layer 1 and create other issues like MEV however de=
ploying them on sidechains should not affect base layer.

>=C2=A0Increasing the Drivechain security parameter leads to slower sidecha=
in->mainchin withdrawals, effectively a bottleneck on how much can be trans=
ferred sidechain->mainchain.

I think 'withdrawals' is the part which can be improved in Drivechain. Not =
sure about any solution at this point or trade-offs involved but making few=
 changes can help Drivechain and Bitcoin.
I agree with everything else you explained and emails like these will be he=
lpful for everyone trying to understand what's going on with Layer 2 on Bit=
coin.

--=20
Prayank

A3B1 E430 2298 178F



Sep 3, 2021, 02:32 by ZmnSCPxj@protonmail.com:

> Good morning Prayank,
>
> Just to be clear, neither Liquid nor RSK, as of my current knowledge, are=
 Drivechain systems.
>
> Instead, they are both federated sidechains.
> The money owned by a federated sidechain is, as far s the Bitcoin blockch=
ain is concerned, really owned by the federation that.runs the sidechain.
>
> Basically, a mainchain->sidechain transfer is done by paying to a federat=
ion k-of-n address and a coordination signal of some kind (details dependin=
g on federated sidechain) to create the equivalent coins on the sidechain.
> A sidechain->mainchain transfer is done by requesting some coins on the s=
idechain to be destroyed, and then the federation will send some of its mai=
nchain k-of-n coins into whatever address you indicate you want to use on t=
he mainchain.
>
> In theory, a sufficient quorum of the federation can decide to ignore the=
 sidechain data entirely and spend the mainchain money arbitrarily, and the=
 mainchain layer will allow this (being completely ignorant of he sidechain=
).
>
> In such federated sidechains, the federation is often a fixed predetermin=
ed signing set, and changes to that federation are expected to be rare.
>
> Federated sidechains are ultimately custodial; as noted above, the federa=
tion could in theory abscond with the funds completely, and the mainchain w=
ould not care if the sidechain federation executes its final exit strategy =
and you lose your funds.
> One can consider federated sidechains to be a custodian with multiple per=
sonality disorder, that happens to use a blockchain to keep its individual =
sub-personalities coordinated with each other, but ultimately control of th=
e money is contingent on the custodian following the dictates of the suppos=
ed owners of the coin.
> From a certain point of view, it is actually immaterial that there is a s=
eparate blockchain called the "sidechain" --- it is simply that a blockchai=
n is used to coordinate the custodians of the coin, but in principle any ot=
her coordination mechanism can be used between them, including a plain data=
base.
>
>
> With Drivechains, custody of the sidechain funds is held by mainchain min=
ers.
> Again, this is still a custodial setup.
> A potential issue here is that the mainchain miners cannot be identified =
(the entire point is anonymity of miners is possible), which may be of conc=
ern.
>
> In particular, note that solely on mainchain, all that miners determine i=
s the *ordering* and *timing* of transactions.
> Let us suppose that there is a major 51% attack attempt on the Bitcoin bl=
ockchain.
> We expect that such an attack will be temporary --- individuals currently=
 not mining may find that their HODLings are under threat of the 51% attack=
, and may find it more economic to run miners at a loss, in order to protec=
t their stacks rather than lose it.
> Thus, we expect that a 51% attack will be temporary, as other miners will=
 arise inevitably to take back control of transaction processing.
> https://github.com/libbitcoin/libbitcoin-system/wiki/Threat-Level-Paradox
>
> In particular, on the mainchain, 51% miners cannot reverse deep history.
> If you have coins you have not moved since 2017, for example, the 51% att=
ack is expected to take about 4 years before it can begin to threaten your =
ownership of those coins (hopefully, in those 4 years, you will get a clue =
and start mining at a loss to protect your funds from outright loss, thus h=
elping evict the 51% attacker).
> 51% miners can, in practice, only prevent transfers (censorship), not for=
ce transfer of funds (confiscation).
> Once the 51% attacker is evicted (and they will in general be evicted), t=
hen coins you owned that were deeply confirmed remain under your control.
>
> With Drivechains, however, sidechain funds can be confiscated by a 51% at=
tacker, by forcing a bogus sidechain->mainchain withdrawal.
> The amount of time it takes is simply the security parameter of the Drive=
chain spec.
> It does not matter if you were holding those funds in the sidechain for s=
everal years without moving them --- a 51% attacker that is able to keep co=
ntrol of the mainchain blockchain, for the Drivechain security parameter, w=
ill be capable of confiscating sidechain funds outright.
> Thus, even if the 51% attacker is evicted, then your coins in the sidecha=
in can be confiscated and no longer under your control.
>
> Increasing the Drivechain security parameter leads to slower sidechain->m=
ainchin withdrawals, effectively a bottleneck on how much can be transferre=
d sidechain->mainchain.
> While exchanges may exist that allow sidechain->mainchain withdrawal fast=
er, those can only operate if the number of coins exiting the sidechain is =
approximately equal to coins entering the sidechain (remember, it is an *ex=
change*, coins are not actually moved from one to the other).
> If there is a "thundering herd" problem, then exchanges will saturate and=
 the sidechain->mainchain withdrawal mechanism has to come into play, and i=
f the Drivechain security parameter (which secures sidechains from 51% atta=
ck confiscation)
> In a "thundering herd" situation, the peg can be lost, meaning that sidec=
hain coins become devalued relative to mainchain coins they are purportedly=
 equivalent to.
>
> A "thundering herd" exiting the sidechain can happen, for example, if the=
 sidechain is primarily used to prototype a new feature, and the feature is=
 demonstrably so desirable that Bitcoin Core actually adds it.
> In that case, the better security of the mainchain becomes desirable, and=
 the sidechain no longer has a unique feature to incentivize keeping your f=
unds there (since mainchain has/will have that feature).
> In that case, the sidechain coin value can transiently drop due to the si=
dechain->mainchain withdrawal bottleneck caused by the Drivechain security =
parameter.
> And if the value can temporarily drop, well, it is not much of a peg, the=
n.
>
> * If the Drivechain security parameter is too low, then a short 51% attac=
k is enough to confiscate all sidechain coins.
> * If the Drivechain seucrity parameter is too large, then a coincidental =
large number of sidechain->mainchain exits risks triggering a thundering he=
rd that temporarily devalues the sidechain value relative to mainchain.
>
> Against 51% attack confiscation, Paul Sztorc I believe proposes a "nuclea=
r option" where mainchain fullnodes are upgraded to ignore historical block=
s created by the 51% attacker.
> The point is that a 51% attacker takes on the risk that confiscation will=
 simply cause everyone to evict all miners and possibly destroy Bitcoin ent=
irely, and rational 51% attackers will not do so, since then their mining h=
ardware becomes useless.
> I believe this leads to a situation where a controversial chainsplit of a=
 sidechain can effectively "infect" mainchain, with competing mainchain min=
ers with different views of the sidechain censoring each other, thus removi=
ng isolation of the sidechain from the mainchain.
>
> --
>
> More to the point: what are sidechains **for**?
>
> * If sidechains are for prototyping new features, then you are probably b=
etter off getting a bunch of developer friends together and creating a fede=
ration that runs the sidechain so you can tinker on new features with frien=
ds.
>  * This is how SegWit was prototyped in Elements Alpha, the predecessor o=
f Liquid.
> * If sidechains are for scaling, then:
>  * We already ***know*** that blockchains cannot scale.
>  * Your plan for scaling is to make ***more*** blockchains?
>  Which we know cannot scale, right?
>  * Good luck.
>
> Now, if we were to consider scaling...
>
> As I pointed out above, in principle a federated sidechain simply decided=
 to use a blockchain to coordinate the federation members.
> Nothing really prevents the federation from using a different mechanims.
>
> In addition, federations (whether signer federations like in RSK or Liqui=
d, or miner federations like in Drivechains) have custodial risk if you put=
 your funds in them.
> The only way to avoid the custodial risk is if ***you*** were one of the =
signatories of the federation, and the federation was an n-of-n.
>
> Now, let us consider a 2-of-2 federation, the smallest possible federatio=
n.
> As long as *you* are one of the two signatories, you have no custodial ri=
sk in putting funds in this federation --- nothing can happen to the mainch=
ain funds without your say-so, so the federation cannot confiscate your fun=
ds.
>
> And again, there is no real need to use a big, inefficient data structure=
 like a **blockchain**.
> In fact, in a 2-of-2 federation, there are only two members, so a lot of =
the blockchain overhead can be reduced to just a bunch of fairly simple pro=
tocol messages you send to each other, no need for a heavy history-retainin=
g append-only data structure.
>
> Of course, only you and the other signatory in this 2-of-2 federation can=
 safely keep funds in that federation.
> You cannot pay a third party with those funds, because that third party n=
ow takes on custodial risk, you and your coutnerparty can collude to steal =
the funds of the third party.
> However, suppose your counterparty was a member of another 2-of-2 federat=
ion, this time with the third party you want to pay.
> You can use an atomic swap mechanism of some kind so that you pay your co=
uterparty if that couterparty pays the third party.
>
> And guess what?
> That is just Lightning Network.
>
> Regards,
> ZmnSCPxj
>


------=_Part_69236_1936841571.1630662465710
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>Good morning&nbsp;ZmnSCPxj,<br></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Thanks for sharing all the details. One thing that I am not su=
re about:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt;&nbsp;=
* We already ***know*** that blockchains cannot scale<br></div><div dir=3D"=
auto">&gt; * Your plan for scaling is to make ***more*** blockchains?<br></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Scaling Bitcoin can be di=
fferent from scaling Bitcoin sidechains. You can experiment with lot of thi=
ngs on sidechains to scale which isn't true for Bitcoin. Most important thi=
ng is requirements for running a node differ. Its easy to run a node for LN=
, Liquid and Rootstock right now. Will it remain the same? I am not sure.<b=
r></div><div dir=3D"auto"><br></div><div dir=3D"auto">LND:&nbsp;https://git=
hub.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Liquid:&nbsp;https://help.blockstream=
.com/hc/en-us/articles/900002026026-How-do-I-set-up-a-Liquid-node-<br></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">Rootstock:&nbsp;https://deve=
lopers.rsk.co/rsk/node/install/<br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">&gt;&nbsp;More to the point: what are sidechains **for**?<br></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Smart contracts are possi=
ble on Bitcoin but with limited functionality so lot of applications are no=
t possible using Bitcoin (Layer1). Some of these don't even make sense on L=
ayer 1 and create other issues like MEV however deploying them on sidechain=
s should not affect base layer.<br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">&gt;&nbsp;Increasing the Drivechain security parameter leads to=
 slower sidechain-&gt;mainchin withdrawals, effectively a bottleneck on how=
 much can be transferred sidechain-&gt;mainchain.<br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">I think 'withdrawals' is the part which can b=
e improved in Drivechain. Not sure about any solution at this point or trad=
e-offs involved but making few changes can help Drivechain and Bitcoin.</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">I agree with everything els=
e you explained and emails like these will be helpful for everyone trying t=
o understand what's going on with Layer 2 on Bitcoin.<br></div><div><br></d=
iv><div>-- <br></div><div>Prayank<br></div><div><br></div><div dir=3D"auto"=
>A3B1 E430 2298 178F<br></div><div><br></div><div><br></div><div><br></div>=
<div>Sep 3, 2021, 02:32 by ZmnSCPxj@protonmail.com:<br></div><blockquote cl=
ass=3D"tutanota_quote" style=3D"border-left: 1px solid #93A3B8; padding-lef=
t: 10px; margin-left: 5px;"><div>Good morning Prayank,<br></div><div><br></=
div><div>Just to be clear, neither Liquid nor RSK, as of my current knowled=
ge, are Drivechain systems.<br></div><div><br></div><div>Instead, they are =
both federated sidechains.<br></div><div>The money owned by a federated sid=
echain is, as far s the Bitcoin blockchain is concerned, really owned by th=
e federation that.runs the sidechain.<br></div><div><br></div><div>Basicall=
y, a mainchain-&gt;sidechain transfer is done by paying to a federation k-o=
f-n address and a coordination signal of some kind (details depending on fe=
derated sidechain) to create the equivalent coins on the sidechain.<br></di=
v><div>A sidechain-&gt;mainchain transfer is done by requesting some coins =
on the sidechain to be destroyed, and then the federation will send some of=
 its mainchain k-of-n coins into whatever address you indicate you want to =
use on the mainchain.<br></div><div><br></div><div>In theory, a sufficient =
quorum of the federation can decide to ignore the sidechain data entirely a=
nd spend the mainchain money arbitrarily, and the mainchain layer will allo=
w this (being completely ignorant of he sidechain).<br></div><div><br></div=
><div>In such federated sidechains, the federation is often a fixed predete=
rmined signing set, and changes to that federation are expected to be rare.=
<br></div><div><br></div><div>Federated sidechains are ultimately custodial=
; as noted above, the federation could in theory abscond with the funds com=
pletely, and the mainchain would not care if the sidechain federation execu=
tes its final exit strategy and you lose your funds.<br></div><div>One can =
consider federated sidechains to be a custodian with multiple personality d=
isorder, that happens to use a blockchain to keep its individual sub-person=
alities coordinated with each other, but ultimately control of the money is=
 contingent on the custodian following the dictates of the supposed owners =
of the coin.<br></div><div>From a certain point of view, it is actually imm=
aterial that there is a separate blockchain called the "sidechain" --- it i=
s simply that a blockchain is used to coordinate the custodians of the coin=
, but in principle any other coordination mechanism can be used between the=
m, including a plain database.<br></div><div><br></div><div><br></div><div>=
With Drivechains, custody of the sidechain funds is held by mainchain miner=
s.<br></div><div>Again, this is still a custodial setup.<br></div><div>A po=
tential issue here is that the mainchain miners cannot be identified (the e=
ntire point is anonymity of miners is possible), which may be of concern.<b=
r></div><div><br></div><div>In particular, note that solely on mainchain, a=
ll that miners determine is the *ordering* and *timing* of transactions.<br=
></div><div>Let us suppose that there is a major 51% attack attempt on the =
Bitcoin blockchain.<br></div><div>We expect that such an attack will be tem=
porary --- individuals currently not mining may find that their HODLings ar=
e under threat of the 51% attack, and may find it more economic to run mine=
rs at a loss, in order to protect their stacks rather than lose it.<br></di=
v><div>Thus, we expect that a 51% attack will be temporary, as other miners=
 will arise inevitably to take back control of transaction processing.<br><=
/div><div>https://github.com/libbitcoin/libbitcoin-system/wiki/Threat-Level=
-Paradox<br></div><div><br></div><div>In particular, on the mainchain, 51% =
miners cannot reverse deep history.<br></div><div>If you have coins you hav=
e not moved since 2017, for example, the 51% attack is expected to take abo=
ut 4 years before it can begin to threaten your ownership of those coins (h=
opefully, in those 4 years, you will get a clue and start mining at a loss =
to protect your funds from outright loss, thus helping evict the 51% attack=
er).<br></div><div>51% miners can, in practice, only prevent transfers (cen=
sorship), not force transfer of funds (confiscation).<br></div><div>Once th=
e 51% attacker is evicted (and they will in general be evicted), then coins=
 you owned that were deeply confirmed remain under your control.<br></div><=
div><br></div><div>With Drivechains, however, sidechain funds can be confis=
cated by a 51% attacker, by forcing a bogus sidechain-&gt;mainchain withdra=
wal.<br></div><div>The amount of time it takes is simply the security param=
eter of the Drivechain spec.<br></div><div>It does not matter if you were h=
olding those funds in the sidechain for several years without moving them -=
-- a 51% attacker that is able to keep control of the mainchain blockchain,=
 for the Drivechain security parameter, will be capable of confiscating sid=
echain funds outright.<br></div><div>Thus, even if the 51% attacker is evic=
ted, then your coins in the sidechain can be confiscated and no longer unde=
r your control.<br></div><div><br></div><div>Increasing the Drivechain secu=
rity parameter leads to slower sidechain-&gt;mainchin withdrawals, effectiv=
ely a bottleneck on how much can be transferred sidechain-&gt;mainchain.<br=
></div><div>While exchanges may exist that allow sidechain-&gt;mainchain wi=
thdrawal faster, those can only operate if the number of coins exiting the =
sidechain is approximately equal to coins entering the sidechain (remember,=
 it is an *exchange*, coins are not actually moved from one to the other).<=
br></div><div>If there is a "thundering herd" problem, then exchanges will =
saturate and the sidechain-&gt;mainchain withdrawal mechanism has to come i=
nto play, and if the Drivechain security parameter (which secures sidechain=
s from 51% attack confiscation)<br></div><div>In a "thundering herd" situat=
ion, the peg can be lost, meaning that sidechain coins become devalued rela=
tive to mainchain coins they are purportedly equivalent to.<br></div><div><=
br></div><div>A "thundering herd" exiting the sidechain can happen, for exa=
mple, if the sidechain is primarily used to prototype a new feature, and th=
e feature is demonstrably so desirable that Bitcoin Core actually adds it.<=
br></div><div>In that case, the better security of the mainchain becomes de=
sirable, and the sidechain no longer has a unique feature to incentivize ke=
eping your funds there (since mainchain has/will have that feature).<br></d=
iv><div>In that case, the sidechain coin value can transiently drop due to =
the sidechain-&gt;mainchain withdrawal bottleneck caused by the Drivechain =
security parameter.<br></div><div>And if the value can temporarily drop, we=
ll, it is not much of a peg, then.<br></div><div><br></div><div>* If the Dr=
ivechain security parameter is too low, then a short 51% attack is enough t=
o confiscate all sidechain coins.<br></div><div>* If the Drivechain seucrit=
y parameter is too large, then a coincidental large number of sidechain-&gt=
;mainchain exits risks triggering a thundering herd that temporarily devalu=
es the sidechain value relative to mainchain.<br></div><div><br></div><div>=
Against 51% attack confiscation, Paul Sztorc I believe proposes a "nuclear =
option" where mainchain fullnodes are upgraded to ignore historical blocks =
created by the 51% attacker.<br></div><div>The point is that a 51% attacker=
 takes on the risk that confiscation will simply cause everyone to evict al=
l miners and possibly destroy Bitcoin entirely, and rational 51% attackers =
will not do so, since then their mining hardware becomes useless.<br></div>=
<div>I believe this leads to a situation where a controversial chainsplit o=
f a sidechain can effectively "infect" mainchain, with competing mainchain =
miners with different views of the sidechain censoring each other, thus rem=
oving isolation of the sidechain from the mainchain.<br></div><div><br></di=
v><div>--<br></div><div><br></div><div>More to the point: what are sidechai=
ns **for**?<br></div><div><br></div><div>* If sidechains are for prototypin=
g new features, then you are probably better off getting a bunch of develop=
er friends together and creating a federation that runs the sidechain so yo=
u can tinker on new features with friends.<br></div><div> * This is how Seg=
Wit was prototyped in Elements Alpha, the predecessor of Liquid.<br></div><=
div>* If sidechains are for scaling, then:<br></div><div> * We already ***k=
now*** that blockchains cannot scale.<br></div><div> * Your plan for scalin=
g is to make ***more*** blockchains?<br></div><div> Which we know cannot sc=
ale, right?<br></div><div> * Good luck.<br></div><div><br></div><div>Now, i=
f we were to consider scaling...<br></div><div><br></div><div>As I pointed =
out above, in principle a federated sidechain simply decided to use a block=
chain to coordinate the federation members.<br></div><div>Nothing really pr=
events the federation from using a different mechanims.<br></div><div><br><=
/div><div>In addition, federations (whether signer federations like in RSK =
or Liquid, or miner federations like in Drivechains) have custodial risk if=
 you put your funds in them.<br></div><div>The only way to avoid the custod=
ial risk is if ***you*** were one of the signatories of the federation, and=
 the federation was an n-of-n.<br></div><div><br></div><div>Now, let us con=
sider a 2-of-2 federation, the smallest possible federation.<br></div><div>=
As long as *you* are one of the two signatories, you have no custodial risk=
 in putting funds in this federation --- nothing can happen to the mainchai=
n funds without your say-so, so the federation cannot confiscate your funds=
.<br></div><div><br></div><div>And again, there is no real need to use a bi=
g, inefficient data structure like a **blockchain**.<br></div><div>In fact,=
 in a 2-of-2 federation, there are only two members, so a lot of the blockc=
hain overhead can be reduced to just a bunch of fairly simple protocol mess=
ages you send to each other, no need for a heavy history-retaining append-o=
nly data structure.<br></div><div><br></div><div>Of course, only you and th=
e other signatory in this 2-of-2 federation can safely keep funds in that f=
ederation.<br></div><div>You cannot pay a third party with those funds, bec=
ause that third party now takes on custodial risk, you and your coutnerpart=
y can collude to steal the funds of the third party.<br></div><div>However,=
 suppose your counterparty was a member of another 2-of-2 federation, this =
time with the third party you want to pay.<br></div><div>You can use an ato=
mic swap mechanism of some kind so that you pay your couterparty if that co=
uterparty pays the third party.<br></div><div><br></div><div>And guess what=
?<br></div><div>That is just Lightning Network.<br></div><div><br></div><di=
v>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote><div dir=3D"auto"><=
br></div>  </body>
</html>

------=_Part_69236_1936841571.1630662465710--