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
|
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 42302BAD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 17:04:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com
[209.85.220.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8F13DCD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 17:04:25 +0000 (UTC)
Received: by mail-qk0-f182.google.com with SMTP id v17so49905947qka.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 10:04:25 -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-transfer-encoding:content-language;
bh=RCaDBAOu/c3oQYEeoxWA/j7acd7ZiMhroaUsSwneZhg=;
b=sHC44BgfCaPijps4W9IaMhe2i6BiWgTgKa74LwY72qL7L1Xn776XIoEmMv8a3xzfKD
a6eQf7qlzGbR7Zs+hCsn18WniymGBOep6+22+TBfSk9jK0czIQvQkHfEZPKDfgTgIn3G
+OfzMzPZGNyrgM6d36eYA3NdGM7hJqzCbwT75ZmoSa0sIS0GLnXnfG2+QJxRmsRy41sh
vnPIsdEziamzQTZAOsHs98Kwce8+CKj82fWrzU73HgtmFTON+x1/SwH9Y5JxIkF3rHv4
fvObQl3rp6fso83n8Fj+hxPIjRreKIuvfw8D+y2n7gzR90+KmFDRFPDXwE7fbw0qRC1t
Ffog==
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-transfer-encoding
:content-language;
bh=RCaDBAOu/c3oQYEeoxWA/j7acd7ZiMhroaUsSwneZhg=;
b=mkWf4TvxQI9Qi2Z12zcELvn8C8G77CpSsHXxUz2fiAhkNVK1Ocpyb03MdPu3xYR/Hx
6sROp81E12ASYY/SbPV1jaRJbVSZFyhpe7M9YXjGRsNNznV/Lp8oGJg91DWLiT6N0FpY
23dkIF9U2E40n0FdKkKGgomWWzfVBCaoJjK2S/kTFSwTBuX6gYw0USg7OxQtv/4CH31l
Y5+CL0ITRETkTeXORBfHozEXklsFc0NjvhgAHVhG47BMdhf/mgbSOdeU1iBKF01z3sE3
CyNnHV10ilQNUGGqlwDP3JrR61Eskja06QmRhgkQLf6Zh4rSRvS9b6G5nZ66bNHfv3p2
Ymfw==
X-Gm-Message-State: AIVw110NjM1tbs7DuyXc+H4UZS8KsgjmkVqFVQx5f1VDdq9L6RvB3F6B
GBb/1g/SubZgrD7d
X-Received: by 10.55.17.198 with SMTP id 67mr6656502qkr.42.1499965464263;
Thu, 13 Jul 2017 10:04:24 -0700 (PDT)
Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
d125sm4482850qkg.43.2017.07.13.10.03.57
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 13 Jul 2017 10:03:57 -0700 (PDT)
To: =?UTF-8?Q?Hampus_Sj=c3=b6berg?= <hampus.sjoberg@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
<42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
<3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
<CAFMkqK_2V+p0JmrAj5WSkEDWXWG4h4c1SzZ4mxEiZBwDpAHd4A@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <dd7bc896-e9f5-c8a2-aaf2-cdcfad43b44c@gmail.com>
Date: Thu, 13 Jul 2017 13:04:01 -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: <CAFMkqK_2V+p0JmrAj5WSkEDWXWG4h4c1SzZ4mxEiZBwDpAHd4A@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: Thu, 13 Jul 2017 17:46:06 +0000
Subject: Re: [bitcoin-dev] Drivechain RfD -- Follow Up
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: Thu, 13 Jul 2017 17:04:26 -0000
Hello,
On 7/13/2017 9:17 AM, Hampus Sj=C3=B6berg wrote:
> In softforks, I would argue that 100% of all nodes and miners need to
> upgrade to the new rules.
> This makes sure that trying to incorrectly spend an "AnyOneCanSpend"
> will result in a hardfork, instead of a temporary (or permanent)
> chainsplit.
>
> With drivechains, it seems like the current plan is to only let the
> nodes that are interested in the drivechain validate the other chain,
> and not necessarily 100% of the network.
Correct.
> I guess this could be any percentage of the network, which could lead
> to a temporary/permanent chainsplit depending on how many percentage
> of the miners are also validating the other chain (am I missing
> something here?).
> I have no way to evaluate if this is an okay trade-off.
> It seems like major disruption could very likely happen if say only 5%
> of all fullnodes validate the drivechain.
You are correct that some % of the network would be validating both
chains. However, if miners improperly withdraw from a sidechain, it --by
design-- does not lead to any chainsplit of any kind. Instead, the
sidechain in question just dies a painful death (notice that, if any
withdrawals are improper, it is quite as bad as if all of the sidechain
funds were withdrawn improperly -- this is because the sidechain would
instantly have a bunch of problems, including that it would be
something-like 'fractional reserve' which would lead to an immediate
bank run of withdrawals [none of which could have any real expectation
of success, in my view]).
In practice, a concern of mine is that people *would* try to turn a
sidechain-theft even into some kind of grand UASF-style campaign. I
would prefer for people not to do this. Then again, I do not hold this
preference unconditionally -- I see it as comparable to Bitcoin's
commitment to "the code is the spec". Which is to say that this
commitment is overwhelmingly held, but not dogmatically as in
exceptional cases such as theValue overflow incident [1].
I think that in such ambiguous cases, we must rely on [a] the miner's
desire to maximize the purchasing power of each Bitcoin, and [b] the
technical wisdom of Bitcoin's future leaders in helping miners to
achieve this goal.
[1] https://en.bitcoin.it/wiki/Value_overflow_incident
> To be fully secure, it seems like 100% of all nodes should also have a
> fullnode for the drivechain as well...
Perhaps, but this is exactly what I am trying to avoid. The design goal,
in some sense, is to have "half security", ie <100%. This is because the
only way to achieve "full" 100% security is with full enforcement of all
rules. Full enforcement of the rules, in turn, means either that we are
exactly where we are right now (where we only add compatible rules, aka
the traditional "soft fork") or we are [also] exactly where we are right
now (in that if we add an incompatible rule, it results in a "hard
fork"). I would like to build something new, which trades off on the
qualities of each, and therefore lies (intentionally) somewhere in betwee=
n.
> This is one of the reasons I don't advocate sidechains/drivechains as
> a scaling solution, it looks like it would have to the same outcome as
> a blocksize increase on the mainchain, but with more complexity.
Keep in mind that, if some people leave the small chain (what you might
call the "Core" chain, although some disagree with summarizing it this
way) for some other chain, it does free up more space on this chain.
I'm not really sure the extent to which that "counts" as increasing
capacity.
Also, I agree that sc/dc do not help with "scalability", if that problem
is defined as "better technology" or as "how to do more with less".
Actually my full view is a little nuanced and it is here:
http://www.drivechain.info/faq/index.html#can-sidechains-really-help-with=
-scaling
> Thanks for all your work so far Paul.
You're welcome!
Paul
|
