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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3808BA91
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 21:40:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com
[209.85.128.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1BAAAC
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 21:40:38 +0000 (UTC)
Received: by mail-wr0-f176.google.com with SMTP id r103so7209440wrb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 14:40:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=aa+dKLcjRIDcHYdu8jbwMn5KoBuYqQG3mnBh9mWes04=;
b=atEZzp2gOlntJFHLaT6+PVfH3CEjl5vMebTlQNM7XdWK1W/L7a0SAWrlHDB14zi+mL
N4E9cbL8herMn61QJCXURPrRXKDWvF/nMdneBd55lOTHDaHMI5E40/FGWb5afSbCJLNK
wG8cuFuVKuEdfLFAQ4uyWrNAKbbvoJ+4F/9Aqo6LBOPnopsX+lvETumAM3c0NQmyP2HD
MIoJYSc2xk5KdfTqX3Euap4hvh+kPwZkBF6FzIbcsrpvFyQifsxmhzVIrEZEhVmHOkJP
QWC2qbyYzg4cuwbBeUhJiWmWE3gFHcNCGdlUN1xsjCggnvIe7IpnOPpNTx06KT6t2FBY
Sqlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=aa+dKLcjRIDcHYdu8jbwMn5KoBuYqQG3mnBh9mWes04=;
b=f6Ivm7BHKx8Z+LFPnWzcjnrnsJKG7BnZzNBfYMPQ/r3YvnwJF5cYuvLhqTxLCQyC5w
9ATNb5apJhpW5rDFmR+LAZNVlVfPOyYI1tGn4XCQ7vifzq2RpLxXJJTn/NFjIbULpHAO
yyGFb8vQSlyiQND7F3Gl5g5Njm647AVC6GoXsIMqw1+HEM1Tc9nAs8yC/ipiGH5cyFu6
uPXFFsuvg1zQoTN15hTKx3EGQq5g4d0uHk7XslunI/GKf8FPw48M6qxRXgsZJvshMirD
yjxNQ1K0/rdFGghEHeSK7kawNPfS6e6+ZjxwSt/j8fknGvc0BdKiifrC5ThpJySDgpiw
idzQ==
X-Gm-Message-State: AIVw112JIz29vRtt4R29esCCpuD36MmOFdDVGE+WBtjU8B7I7ipaxnU5
xp2PPJoOYqry2DePUaqaH46W0UrJ2w==
X-Received: by 10.80.181.80 with SMTP id z16mr3910738edd.6.1499809237234; Tue,
11 Jul 2017 14:40:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.222.141 with HTTP; Tue, 11 Jul 2017 14:40:36 -0700 (PDT)
In-Reply-To: <d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@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>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Tue, 11 Jul 2017 14:40:36 -0700
Message-ID: <CAPg+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>
Content-Type: text/plain; charset="UTF-8"
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 21:54:15 +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 21:40:39 -0000
On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
> 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.
> 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".
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.
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.
> 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.
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.
Cheers,
--
Pieter
|
