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
|
Return-Path: <marcel@jamin.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 16643268
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 13:07:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com
[209.85.160.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 263AD1AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 13:07:44 +0000 (UTC)
Received: by ykdu72 with SMTP id u72so58448717ykd.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 06:07:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=5bhLQIrzQclFFpf11jo8VhY9ZU5liO4MM7n66lZMFvk=;
b=R0DouLHv6z4/VEmdYUI7mUdOjVtrNJVg7EtLfswIOsj9d6K1gllWn97s7PpGOMzkVd
TcyqjY7vSRjIMdGfxN65/k5VHDO24VaTZv5Y6iZzb/iJxLWNpU93onfc9D2wAMCfMGbA
UiifOd6xQqDgn20/6Gg6N/HA3RlFs5kSc8noDSz6Qv8jOv1UW7+947pf5I7pFd2f2V8Q
hb7XMMRxi8G5ut7cHgUqYNZiLlYlTpdsoIOZEo4WGksCwxhyroUDTjVI1hoIoUgujd4r
FA8RrbZ6kF7E+dPBibB3EFjFw0pF7N5Rt3+lEW+1vzdOM62gePXYm6hEih8xP09xfx4/
gwTA==
X-Gm-Message-State: ALoCoQmzFNU5i916Bz408GIOzMlC5egHLZIPBTgbkt+CedRR96WHfi3TgqqYpNI1UaAAxzKSp+TG
MIME-Version: 1.0
X-Received: by 10.129.117.196 with SMTP id q187mr3050592ywc.15.1438348063047;
Fri, 31 Jul 2015 06:07:43 -0700 (PDT)
Received: by 10.13.224.69 with HTTP; Fri, 31 Jul 2015 06:07:42 -0700 (PDT)
In-Reply-To: <CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
Date: Fri, 31 Jul 2015 15:07:42 +0200
Message-ID: <CAAUq487KW00xWhL=4UPrd6O37aKmSAN7Jdo_h_8j41z+reUzOA@mail.gmail.com>
From: Marcel Jamin <marcel@jamin.net>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a1147f7285cb153051c2b81f9
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 31 Jul 2015 13:07:45 -0000
--001a1147f7285cb153051c2b81f9
Content-Type: text/plain; charset=UTF-8
> Quite possibly bigger blocks == more users == more nodes and more miners.
I agree and would say that this is the only prediction of bitcoin's future
we can be absolutely sure of: more users equals more decentralization as
long as the cost of running a node is not prohibitively high.
It's incredibly cheap today and won't be too high with any of the current
proposals for the time being. If the "laws" of Nielsen & co suddenly don't
apply anymore, we can always react to that with another hardfork reducing
the rate of growth. Hardforks are way easier if the network is in danger
and the necessary change is obvious and non-controversial (e.g. "reduce
blocksize limit growth").
As long as hobbyists can participate in running the network and it's
affordable for everyone to transact on it, bitcoin will grow and its
decentralization with it, however you measure it.
2015-07-31 14:15 GMT+02:00 Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> Hey Jorge,
>
> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.
>
> To repeat: it's not obvious to me at all that everything wrong with
> Bitcoin can be solved by shrinking blocks. I don't think that's going to
> suddenly make everything magically more decentralised.
>
> The 8mb cap isn't quite arbitrary. It was picked through negotiation with
> different stakeholders, in particular, Chinese miners. But it should be
> high enough to ensure organic growth is not constrained, which is good
> enough.
>
> I think it would be nice to have some sort of simulation to calculate
>> a "centralization heuristic" for different possible blocksize values
>> so we can compare these arbitrary numbers somehow.
>
>
> Centralization is not a single floating point value that is controlled by
> block size. It's a multi-faceted and complex problem. You cannot "destroy
> Bitcoin through centralization" by adjusting a single constant in the
> source code.
>
> To say once more: block size won't make much difference to how many
> merchants rely on payment processors because they aren't using them due to
> block processing overheads anyway. So trying to calculate such a formula
> won't work. Ditto for end users on phones, ditto for developers who want
> JSON/REST access to an indexed block chain, or hosted wallet services, or
> miners who want to reduce variance.
>
> None of these factors have anything to do with traffic levels.
>
> What people like you are Pieter are doing is making a single number a kind
> of proxy for all fears and concerns about the trend towards outsourcing in
> the Bitcoin community. Everything gets compressed down to one number you
> feel you can control, whether it is relevant or not.
>
> > So why should anyone go through the massive hassle of setting up
>> exchanges,
>> > without the lure of large future profits?
>>
>> Are you suggesting that bitcoin consensus rules should be designed
>> to maximize the profits of Bitcoin exchanges?
>>
>
> That isn't what I said at all Jorge. Let me try again.
>
> Setting up an exchange is a lot of risky and expensive work. The
> motivation is profit, and profits are higher when there are more users to
> sell to. This is business 101.
>
> If you remove the potential for future profit, you remove the motivation
> to create the services that we now enjoy and take for granted. Because if
> you think Bitcoin can be useful without exchanges then let me tell you, I
> was around when there were none. Bitcoin was useless.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1147f7285cb153051c2b81f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8000001907349px">Qui=
te possibly bigger blocks =3D=3D more users =3D=3D more nodes and more mine=
rs.</span><div><span style=3D"font-size:12.8000001907349px"><br></span></di=
v><div><span style=3D"font-size:12.8000001907349px">I agree and would say t=
hat this is the only prediction of bitcoin's future we can be absolutel=
y sure of: more users equals more decentralization as long as the cost of r=
unning a node is not prohibitively high.</span></div><div><span style=3D"fo=
nt-size:12.8000001907349px"><br></span></div><div><span style=3D"font-size:=
12.8000001907349px">It's incredibly cheap today and won't be too hi=
gh with any of the current proposals for the time being. If the "laws&=
quot; of Nielsen & co suddenly don't apply anymore, we can always r=
eact to that with another hardfork reducing the rate of growth. Hardforks a=
re way easier if the network is in danger and the necessary change is obvio=
us and non-controversial (e.g. "reduce blocksize limit growth").<=
/span></div><div><br></div><div>As long as hobbyists can participate in run=
ning the network and it's affordable for everyone to transact on it, bi=
tcoin will grow and its decentralization with it, however you measure it.</=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-07=
-31 14:15 GMT+02:00 Mike Hearn via bitcoin-dev <span dir=3D"ltr"><<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>></span>:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Hey Jorge,<br><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">He is =
not saying that. Whatever the reasons for centralization are, it<br>
is obvious that increasing the size won't help.<br></blockquote><div><b=
r></div></span><div>It's not obvious. Quite possibly bigger blocks =3D=
=3D more users =3D=3D more nodes and more miners.</div><div><br></div><div>=
To repeat: it's not obvious to me at all that everything wrong with Bit=
coin can be solved by shrinking blocks. I don't think that's going =
to suddenly make everything magically more decentralised.</div><div><br></d=
iv><div>The 8mb cap isn't quite arbitrary. It was picked through negoti=
ation with different stakeholders, in particular, Chinese miners. But it sh=
ould be high enough to ensure organic growth is not constrained, which is g=
ood enough.</div><span class=3D""><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">I think it would be nice to have some sort of simulation to calculate<=
br>
a "centralization heuristic" for different possible blocksize val=
ues<br>
so we can compare these arbitrary numbers somehow. </blockquote><div><br></=
div></span><div>Centralization is not a single floating point value that is=
controlled by block size. It's a multi-faceted and complex problem. Yo=
u cannot "destroy Bitcoin through centralization" by adjusting a =
single constant in the source code.</div><div><br></div><div>To say once mo=
re: block size won't make much difference to how many merchants rely on=
payment processors because they aren't using them due to block process=
ing overheads anyway. So trying to calculate such a formula won't work.=
Ditto for end users on phones, ditto for developers who want JSON/REST acc=
ess to an indexed block chain, or hosted wallet services, or miners who wan=
t to reduce variance.</div><div><br></div><div>None of these factors have a=
nything to do with traffic levels.</div><div><br></div><div>What people lik=
e you are Pieter are doing is making a single number a kind of proxy for al=
l fears and concerns about the trend towards outsourcing in the Bitcoin com=
munity. Everything gets compressed down to one number you feel you can cont=
rol, whether it is relevant or not.</div><span class=3D""><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span>> So why should anyone go through the=
massive hassle of setting up exchanges,<br>
> without the lure of large future profits?<br>
<br>
</span>Are you suggesting that bitcoin consensus rules should be designed t=
o=C2=A0maximize the profits of Bitcoin exchanges?<br></blockquote><div><br>=
</div></span><div>That isn't what I said at all Jorge. Let me try again=
.</div><div><br></div><div>Setting up an exchange is a lot of risky and exp=
ensive work. The motivation is profit, and profits are higher when there ar=
e more users to sell to. This is business 101.</div><div><br></div><div>If =
you remove the potential for future profit, you remove the motivation to cr=
eate the services that we now enjoy and take for granted. Because if you th=
ink Bitcoin can be useful without exchanges then let me tell you, I was aro=
und when there were none. Bitcoin was useless.</div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--001a1147f7285cb153051c2b81f9--
|
