1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
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
|
