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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F3E9CA82
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 20:36:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com
[209.85.216.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F1FCCE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 20:36:35 +0000 (UTC)
Received: by mail-qt0-f171.google.com with SMTP id b40so3253506qtb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 13:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-language;
bh=A7cGXP4jutQ3Q1Ojk/8/aVNb+bQwckzQwgTYP4bnc9A=;
b=FkBl0YUryW/CjBNWwlP+tzDPvFgmB0coWRLcJTO3PbEOw/YnE7rJcKLusQxoLNbPiG
E9ceQ77O3jstV6BU+rLNaffVuyIYZwcjHQIclxzNGHAEXTBio2A3xevQ0Dd+DxfRxuEA
Wdjybbz9Q9NGY563r1C6ZOx3JYzNsqUyFUNKU7UJnYScd729FzFlysf9AtrXMf1iwjEX
6oKiNCD081yhXKxF3KEpO91jjtcPr/KgPhI+jfQ0Uy99kmRShGWwmTip1cUn2iBKm3KS
8zDiClXQis2tgaSJxAq8dTu1MzrydIdifaVKTS8nOI6QWmpzZmAKe56n4vMtChU2lzLH
qHFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language;
bh=A7cGXP4jutQ3Q1Ojk/8/aVNb+bQwckzQwgTYP4bnc9A=;
b=i/5JFQFHNu/d46KqCZQoEuz8kqerw34ht+ZuH66YgBgriSqceZ4IjcJ41RFzVWZWR7
PV8inbhFR1kZYedWqtMEEXbdV0A0HJKU1hjQzB7gycdywAUbJo4dvAuuR9t3u7hLc9ZS
zM4YhZa/2JC7CJ4PaFiqQtXt3iMFwC5giMozZMtYacUxzSV4LXN1NkUV/pLNPAfPmjJ4
3zR283Aqxe+jTz/Tu3CaVzvNMHb7pPsoBMt1mjd3IiNSKS8lYgGT/nM0/lb1op/SzPyF
VpiuGcSFNlPbhWFkC4tMxsxF+vP/V+1hU0s1pPhkdruRECIUkzxSVjiMM/2t6Sz4bT9p
xCIg==
X-Gm-Message-State: AIVw113up7hKzJCyGEeWl/ppq8/RC3VOCl7S1nZCnrKlQ1Qeg4OCqJci
kvrzbJWz+BzVFFxS
X-Received: by 10.200.14.12 with SMTP id a12mr2357281qti.115.1499805393992;
Tue, 11 Jul 2017 13:36:33 -0700 (PDT)
Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
s12sm265969qtc.52.2017.07.11.13.36.32
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 11 Jul 2017 13:36:33 -0700 (PDT)
To: Pieter Wuille <pieter.wuille@gmail.com>,
Chris Stewart <chris@suredbits.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
<CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@gmail.com>
Date: Tue, 11 Jul 2017 16:36:36 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------3942536F8EE65F365D786F97"
Content-Language: en-US
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 11 Jul 2017 21:09:45 +0000
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 11 Jul 2017 20:36:36 -0000
This is a multi-part message in MIME format.
--------------3942536F8EE65F365D786F97
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Pieter,
I think that you have misrepresented Chris' view by taking it out of
context. His complete quote reads "If drivechains are successful they
should be viewed as the way we scale -- not hard forking the protocol."
Chris is comparing Drivechains/sidechains to a hard fork.
You went on to "disagree", but every point of contention you introduced
was something that would apply to both drivechain-sourced capacity and
hardfork-sourced capacity. Neither improves scalability, and both allow
users only the opportunity to select a different security model. If I
understand you, the point at which a security model does not become
"interesting" to you, would be the exact same point in the drivechain
and hardfork worlds. Both, at any rate, have the same effect on
"validation cost to auditors".
The only true difference is the "extra risk of miners being able to vote
to steal your money", but as I have pointed out on this mailing list
several times, I do not actually believe that there is any marginal risk
-- miners can already "vote to steal your money" in the double-spend and
ln-channel-theft contexts. I have also argued that the "risk" is
actually desirable in an opt-in context, because it puts the burden of
proof on miners/developers (to convince users that they should move over
to the sidechain). Since their sidechain coins cannot appreciate in
value relative to the mainchain coins, users would only opt-in if they
felt that they were sufficiently compensated for any and all risks.
Hence, it is difficult to list this item as a drawback when, to the
user, it is a strict improvement (at least, by any epistemological
standard that I can think of). If you have new objections to these
claims, I'm sure we would all benefit from hearing them, myself most of a=
ll.
Paul
On 7/11/2017 4:01 PM, Pieter Wuille wrote:
> On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Concept ACK.
>
> If drivechains are successful they should be viewed as the way we
> scale
>
>
> I strongly disagree with that statement.
>
> Drivechains, and several earlier sidechains ideas, are not a
> scalability improvement, but merely enabling users to opt-in for
> another security model.
>
> While obviously any future with wider adoption will need different
> technologies that have different trade-offs, and anyone is free to
> choose their security model, I don't think this particular one is
> interesting. In terms of validation cost to auditors, it is as bad as
> just a capacity increase on chain, while simultaneously adding the
> extra risk of miners being able to vote to steal your money.
>
> Cheers,
>
> --=20
> Pieter
>
--------------3942536F8EE65F365D786F97
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Pieter, <br>
<br>
I think that you have misrepresented Chris' view by taking it out
of context. His complete quote reads "If drivechains are
successful they should be viewed as the way we scale -- not hard
forking the protocol." Chris is comparing Drivechains/sidechains
to a hard fork.<br>
<br>
You went on to "disagree", but every point of contention you
introduced was something that would apply to both
drivechain-sourced capacity and hardfork-sourced capacity. Neither
improves scalability, and both allow users only the opportunity to
select a different security model. If I understand you, the point
at which a security model does not become "interesting" to you,
would be the exact same point in the drivechain and hardfork
worlds. Both, at any rate, have the same effect on "validation
cost to auditors".<br>
<br>
The only true difference is the "extra risk of miners being able
to vote to steal your money", but as I have pointed out on this
mailing list several times, I do not actually believe that there
is any marginal risk -- miners can already "vote to steal your
money" in the double-spend and ln-channel-theft contexts. I have
also argued that the "risk" is actually desirable in an opt-in
context, because it puts the burden of proof on miners/developers
(to convince users that they should move over to the sidechain).
Since their sidechain coins cannot appreciate in value relative to
the mainchain coins, users would only opt-in if they felt that
they were sufficiently compensated for any and all risks. Hence,
it is difficult to list this item as a drawback when, to the user,
it is a strict improvement (at least, by any epistemological
standard that I can think of). If you have new objections to these
claims, I'm sure we would all benefit from hearing them, myself
most of all.<br>
<br>
Paul<br>
<br>
<br>
On 7/11/2017 4:01 PM, Pieter Wuille wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com">
<div dir="ltr">
<div dir="auto">
<div class="gmail_extra" dir="auto">
<div class="gmail_quote">On Jul 11, 2017 09:18, "Chris
Stewart via bitcoin-dev" <<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>>
wrote:<br type="attribution">
<blockquote
class="m_-8083649854125578197m_-8689624958029859536quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>Concept ACK.<br>
<br>
</div>
If drivechains are successful they should be
viewed as the way we scale</div>
</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I strongly disagree with that statement.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Drivechains, and several earlier sidechains
ideas, are not a scalability improvement, but merely
enabling users to opt-in for another security model.<br>
<br>
</div>
<div dir="auto">While obviously any future with wider adoption
will need different technologies that have different
trade-offs, and anyone is free to choose their security
model, I don't think this particular one is interesting. In
terms of validation cost to auditors, it is as bad as just a
capacity increase on chain, while simultaneously adding the
extra risk of miners being able to vote to steal your money.</div>
<div dir="auto"><br>
</div>
<div>Cheers,<br>
<br>
-- <br>
</div>
<div>Pieter<br>
<br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>
--------------3942536F8EE65F365D786F97--
|
