Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 550AFC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  7 Sep 2021 09:37:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 366D8401E9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  7 Sep 2021 09:37:53 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.598
X-Spam-Level: *
X-Spam-Status: No, score=1.598 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, 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, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id irIxxZFSenJE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  7 Sep 2021 09:37:52 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DBCE040119
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  7 Sep 2021 09:37:51 +0000 (UTC)
Date: Tue, 07 Sep 2021 09:37:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1631007468;
 bh=z+dbLDfu8PycHsv+M5IwckNKHG05NtfNjjXC/sRW4Sw=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=GXY4XUvhXjcVGRrkHl9EUNT0r48+4bc2k4aKwgqo859874oHUx7Ep3rHKspC1w7o2
 Us7vvZO+BioeB8OhyaazzCopNenAmrBPZudQlyMBwSJXkW3iF0li2tXbyoyQvOIiFB
 sqFPHlSXmvl4tVvg3FZqySbBjdLGNTx2Yunr9qy0=
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
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: Tue, 07 Sep 2021 09:37:53 -0000

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