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
|
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 7029F4A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 22:49:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
[209.85.220.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCA9D1ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 22:49:18 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id p21so5565425qke.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 15:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:cc:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-transfer-encoding:content-language;
bh=Cn5vagZGmkp+j7cJnwajflxbiao6He75vZygXIAQz5w=;
b=G27SPUhC1X7gneQEbxjTXT5b/txwRGXW+a8ChHkKWcNJcioDHSbNCA8Y4AAlBBQGc9
FEJUnP08BFdm6a7c2aXXS0UEsX/6/1DCxTmvGuIx4l4CSjxjer84N+dyqW7JLBROqFZq
hVSJkXX3BhuyuWhe7SnmhLp6vZe9E4X/kLBpqq1umFGagolnGCG3PhzMU6V0HYs1BFQR
fjxRLlXfWnHVhUi7UoiT+TgRdK8qMngrSGCiLvQsUiCOJl6qVatNhqFyrVBaaAautvhL
7Z9PeXE+GM+j7FFPA4bejbT0jpFI/G4sw24LFQ6lxfYkSwrqCKQ9eAyBYSb+eFQ9imB0
5quw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:cc:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
:content-language;
bh=Cn5vagZGmkp+j7cJnwajflxbiao6He75vZygXIAQz5w=;
b=f03GjLqq1E8HldRjiTIFkIK974llqi5DfqKFCWRDLvEQytXxS2/s3s1agexm68pDOQ
yRMJbAB2XKgNFs7cUlMuZrbtXg/P9ijjNDuH1QuTWHiytOnwwLJ/sZjJDxWX0N0lrEbc
Gn+PKAraHCxAkLjZG7uucVKlYyxndLM7WKcZ8H578fFfRyjeowC1oqqdBBrBofcTzTHY
tMf5R0LwXLgnCkZcxmeC3iOmKUKPAWRKhkuVC5jyMDafFXx0su+qngtj5BUd8v21FQUt
SGTC1kZwdoA9r4BqTJJKtzB3CzGzl6zvB0rYGaGSSBmbvnYfkHry4gdlwN8O2SUR2KPf
i7UQ==
X-Gm-Message-State: AIVw113kLYLwoU32eUYWp44EjSpQdE4kvki0a4VxkMUeF2I777dVRPqL
N7r+eBclel1USRN2
X-Received: by 10.55.157.135 with SMTP id g129mr2641245qke.241.1499813357546;
Tue, 11 Jul 2017 15:49:17 -0700 (PDT)
Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
x25sm513813qth.61.2017.07.11.15.49.16
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 11 Jul 2017 15:49:16 -0700 (PDT)
To: Pieter Wuille <pieter.wuille@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
<CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com>
<d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@gmail.com>
<CAPg+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <93a5f7e8-08ee-06a8-f638-b4e85814d598@gmail.com>
Date: Tue, 11 Jul 2017 18:49:19 -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+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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, 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 23:01:41 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 22:49:19 -0000
On 7/11/2017 5:40 PM, Pieter Wuille wrote:
> On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin@gmail.com> wrot=
e:
>> 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.
> I apologize here; I didn't mean to misrepresent his viewpoint.
I'm sure you did not intend to do so, of course.
>> You went on to "disagree", but every point of contention you introduce=
d was
>> something that would apply to both drivechain-sourced capacity and
>> hardfork-sourced capacity. Neither improves scalability, and both allo=
w
>> 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 "validatio=
n cost
>> to auditors".
> If you're talking about the extreme case where every full node in the
> increased capacity single chain model corresponds to a node that
> validates both chains and all transfers between them in the
> drivechains, I agree. At that point they become nearly equivalent in
> terms of ease of adoption, resource costs, and capacity.
>
> However, I don't think that is a realistic expectation. When
> considering drivechains as a capacity increase, I believe most people
> think about a situation where there are many chains that give an
> increased capacity combined, but not everyone verifies all of them.
> This is what I meant with uninteresting security model, as it requires
> increased miner trust for preventing the other chains' coins from
> being illegally transferred to the chain you're operating on.
I think I understand what you are saying, but in this case "it" [your
experience] isn't a different security model *for you*. Perhaps we
disagree on the significance of this qualification.
It seems to be me that your position puts you in danger of having to go
out and protect users from investing in insecure _Altcoins_. Probably,
in a world where altcoins were magically impossible, there would be an
even greater demand for Bitcoin capacity than there is in our
Altcoin-filled world (for a few reasons).
> Regardless, people are free experiment and adopt such an approach. The
> nice thing about it not being a hardfork is that it does not require
> network-wide consensus to deploy. However, I don't think they offer a
> security model that should be encouraged, and thus doesn't have a
> place on a roadmap.
I think this is reasonable. It is true that, if no one used drivechains
ever for anything, there would be no transactions offloaded to those
chain, and then no capacity freed up on the original mainchain.
However, though I think your logic is correct in general, I think in
this specific instance it would be somewhat unreasonable to ignore the
fact that, today, we have clear evidence that many people *are* in fact
chomping at the bit to literally leave this blockchain for one that is
almost identical save for a larger maxblocksize.
>> 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 improve=
ment
>> (at least, by any epistemological standard that I can think of). If yo=
u have
>> new objections to these claims, I'm sure we would all benefit from hea=
ring
>> them, myself most of all.
> Am I right in summarizing your point here as "This approach cannot
> hurt, because if it were insecure, people can choose to not use it."?
> I'm not sure I agree with that, as network effects or misinformation
> may push users beyond what is reasonable.
Again, I think you may be right. However, users may be similarly misled
in the case of Altcoins (or in the case of investments in fiat
currency), and they may be misled in their use of all kinds of
cryptographic software, and in the clothes that they buy and all of
their other activities.
I would strongly support clear expectations, and constant reminders to
users that the security models are different. Perhaps, even, annoying
dialogue boxes that pop up when/if a user tries to move their funds to a
sidechain.
But, again, this (I think) is something that would *also* apply to a
hard fork. We cannot know if Pieter Wuille, for example, believes that a
given hard fork is "push[ing] users beyond what is reasonable" until we
ask him.
--Paul
|
