Date: Tue, 07 Sep 2021 09:37:43 +0000
To: Prayank <prayank@tutanota.de>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <fUQB1iJaia8hKE2X25B7MeBnqn78XEHzRBXO8OiZ4VIFwyk5TMBqyAgeZumeScl1jcKFS0nGW79Rkd7HqhIcB7-11Bw7jPS_ZNBGjXx-Q4s=@protonmail.com>
In-Reply-To: <Mif2dMR--3-2@tutanota.de>
References: <MibU_fn--3-2@tutanota.de>
 <3dyAATLXbsE7WBzpVIc0s4sRkSFhR_5NN04uUgx3o9LH48IKR6EHL3V45PfpRM96yxHXdsjd7WC7MGuPlBw7MRpCkpXRsB-WI7i3-Nr13Ew=@protonmail.com>
 <Mif2dMR--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain: BIP 300 and 301
Precedence: list

Good morning Prayank,


> 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=
 experiment with lot of things on sidechains to scale which isn't true for =
Bitcoin.

I would classify this as "prototyping new features" (i.e. it just happens t=
o be a feature that theoretically improves blockchain scaling, with the sid=
echain as a demonstration and the goal eventually to get something like it =
into Bitcoin blockchain proper), not really scaling-by-sidechains/shards, s=
o I think this is a fine example of "just make a federated sidechain" solut=
ion for the prototyping bit.

Do note that the above idea is a kernel for the argument that Drivechains s=
imply allow for miner-controlled block size increases, an argument I have s=
een elsewhere but have no good links for, so take it is hearsay.

> 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 the sa=
me? I am not sure.
>
> LND:=C2=A0https://github.com/lightningnetwork/lnd/blob/master/docs/INSTAL=
L.md
>
> Liquid:=C2=A0https://help.blockstream.com/hc/en-us/articles/900002026026-=
How-do-I-set-up-a-Liquid-node-
>
> Rootstock:=C2=A0https://developers.rsk.co/rsk/node/install/

LN will likely remain easy to install and maintain, especially if you use C=
-Lightning and CLBOSS *cough*.

> >=C2=A0More to the point: what are sidechains **for**?
>
> Smart contracts are possible on Bitcoin but with limited functionality so=
 lot of applications are not possible using Bitcoin (Layer1). Some of these=
 don't even make sense on Layer 1 and create other issues like MEV however =
deploying them on sidechains should not affect base layer.

Key being "should" --- as noted, part of the Drivechains security argument =
from Paul Sztorc is that a nuclear option can be deployed, which *possibly*=
 means that issues in the sidechain may infect the mainchain.

Also see stuff like "smart contracts unchained": https://zmnscpxj.github.io=
/bitcoin/unchained.html
This allows creation of small federations which are *not* coordinated via i=
nefficient blockchain structures.

So, really, my main point is: before going for the big heavy blockchain ham=
mer, maybe other constructions are possible for any specific application?

>
> >=C2=A0Increasing the Drivechain security parameter leads to slower sidec=
hain->mainchin withdrawals, effectively a bottleneck on how much can be tra=
nsferred sidechain->mainchain.
>
> I think 'withdrawals' is the part which can be improved in Drivechain. No=
t sure about any solution at this point or trade-offs involved but making f=
ew changes can help Drivechain and Bitcoin.

It is precisely due to the fact that the mainchain cannot validate the side=
chain rules, that side->main transfers must be bottlenecked, so that sidech=
ain miners have an opportunity to gainsay any theft attempts that violate t=
he sidechain rules.
Consider a similar parameter in Lightning when exiting non-cooperatively fr=
om a channel, which allows the other side to gainsay any theft attempts, a =
parameter which will still exist even in Decker-Russell-Osuntokun.

This parameter existed even in the old Blockstream sidechains proposal from=
 sipa et al.
For the old Blockstream proposal the parameter is measured in sidechain blo=
cks, and the sidechain has its own miners instead of riding off mainchain, =
but ultimately there exists a parameter that restricts the rate at which si=
de->main transfers can be performed.

At least LN does not require any changes at the base layer (at least not an=
ymore, after SegWit).

Regards,
ZmnSCPxj