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
|
Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D9C5D8C7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 12:19:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com
[209.85.215.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ACB4412A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 12:19:39 +0000 (UTC)
Received: by labsr2 with SMTP id sr2so5863749lab.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 04 Aug 2015 05:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=qTkAHf8Mx0OhO5ywQ80keceuTgtkTvcbLWxATTRdNIA=;
b=hKts86MoE8+EF1c9ooct+89MlGHEFcZKr3ZQ6RmJt5YaNIhPkVTJngzjywYgciPGQ9
XDrTt4+1ovlEBiA48FA8B6yP5KwVD/EBTl/gfH5wVgJCM8DCRwTc9mj9Hz9FVxdB7FEm
uTATDArVZmpx3Ldmfxh91ZwJdeqhexMxDQSEQpx5VVvlx/YvNwiLZSx3s8+j4TL6BXLk
yMq0udPoWTCxJuime5fzXApPEA8JnsFwV412YU6wNHreBbVC8wvVl8iVrfG+7FjzVxfa
a3oLltzs8nvkhfTeqbPXW0jZiTevw3T5+FioWbdK4auEwzGOBJlTrUlGv3ifWJLdy2i2
8ZmA==
X-Received: by 10.152.10.148 with SMTP id i20mr2986947lab.63.1438690777986;
Tue, 04 Aug 2015 05:19:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Tue, 4 Aug 2015 05:19:18 -0700 (PDT)
In-Reply-To: <CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@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>
<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Tue, 4 Aug 2015 13:19:18 +0100
Message-ID: <CAAO2FKHJMbt2kpJy+sLTNWAgBwdxZNoEbcUsVF7rbXgbjTx4yQ@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a11331df0c37d6e051c7b4c66
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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: Tue, 04 Aug 2015 12:19:41 -0000
--001a11331df0c37d6e051c7b4c66
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 4 August 2015 at 12:59, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> That is not my position. Again, I don't know what the right blocksize
> for the short term is (I don't think anybody does).
>
You have no position (i.e. neutral). In other words, keeping the existing
limit.
> Therefore how the change can affect mining centralization must be the
> main concern, instead of (also artificial) projections about usage
> growth (no matter how organic their curves look).
>
The degree of mining decentralization is only one of many concerns. Users'
main concern is timely confirmation of low-fee transactions. Miners'
concern is the amount of profit they make.
> Also I don't think "hitting the limit" must be necessarily harmful and
> if it is, I don't understand why hitting it at 1MB will be more
> harmful than hitting it at 2MB, 8MB or 8GB.
>
The limit won't even get to be hit, because all the users that get thrown
out of Bitcoin will have moved over to a system supporting a larger block
size.
I don't know where you get your "majority" from or what it even means
> (majority of users, majority of the coins, of miners?)
>
The majority which the miners are beholden to is the economic majority.
https://en.bitcoin.it/wiki/Economic_majority
> But there's something I'm missing something there...why my position
> doesn't matter if it's not a majority?
>
Your position is only one of many and it does not carry excess weight to
the others. Individually it won't matter, because you can't control the
implementation that other people run.
> How is what the the majority has been told it's best an objective argumen=
t?
>
Don't fight the market. The way the system is designed, the miners will
follow along with what the economic majority have decided.
So if you say 8, I must ask, why not 9?
> Why 9 MB is not safe for mining centralization but 8 MB is?
>
8MB has simply been the focal point for this debate. 9MB is also safe if
8MB is, but I suppose the opponents will be even less happy with 9 than
with 8, and we don't want to unnecessarily increase the conflict.
It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be effectively
> any limit in the long term and Bitcoin will probably fail in its
> decentralization goals.
>
A one-time increase to 8MB is safer than a dynamically growing limit over
time for exactly this reason. Admittedly whenever the next debate to
increase the block size over 8MB happens it will be even more painful and
non-obvious, but that is the safety check to prevent unbounded block size
increase.
--001a11331df0c37d6e051c7b4c66
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 4=
August 2015 at 12:59, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D"ma=
ilto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">That is not my position. Again, I do=
n't know what the right blocksize<br>
for the short term is (I don't think anybody does).<br></blockquote><di=
v><br></div><div>You have no position (i.e. neutral). In other words, keepi=
ng the existing limit.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>Therefore how the change can affect mining centralization must be the<br>
main concern, instead of (also artificial) projections about usage<br>
growth (no matter how organic their curves look).<br></blockquote><div><br>=
</div><div>The degree of mining decentralization is only one of many concer=
ns. Users' main concern is timely confirmation of low-fee transactions.=
Miners' concern is the amount of profit they make.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
Also I don't think "hitting the limit" must be necessarily ha=
rmful and<br>
if it is, I don't understand why hitting it at 1MB will be more<br>
harmful than hitting it at 2MB, 8MB or 8GB.<br></blockquote><div><br></div>=
<div>The limit won't even get to be hit, because all the users that get=
thrown out of Bitcoin will have moved over to a system supporting a larger=
block size.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't=
know where you get your "majority" from or what it even means<br=
>
(majority of users, majority of the coins, of miners?)<br></blockquote><div=
><br></div><div>The majority which the miners are beholden to is the econom=
ic majority.</div><div><a href=3D"https://en.bitcoin.it/wiki/Economic_major=
ity">https://en.bitcoin.it/wiki/Economic_majority</a><br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
But there's something I'm missing something there...why my position=
<br>
doesn't matter if it's not a majority?<br></blockquote><div><br></d=
iv><div>Your position is only one of many and it does not carry excess weig=
ht to the others. Individually it won't matter, because you can't c=
ontrol the implementation that other people run.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
How is what the the majority has been told it's best an objective argum=
ent?<br></blockquote><div><br></div><div>Don't fight the market. The wa=
y the system is designed, the miners will follow along with what the econom=
ic majority have decided.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">So if you say 8, I must ask, why not 9?<br>
Why 9 MB is not safe for mining centralization but 8 MB is?<br></blockquote=
><div><br></div><div>8MB has simply been the focal point for this debate. 9=
MB is also safe if 8MB is, but I suppose the opponents will be even less ha=
ppy with 9 than with 8, and we don't want to unnecessarily increase the=
conflict.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems like=
the rationale it's always "the bigger the better" and<br>
the only limitation is what a few people concerned with mining<br>
centralization (while they still have time to discuss this) are<br>
willing to accept. If that's the case, then there won't be effectiv=
ely<br>
any limit in the long term and Bitcoin will probably fail in its<br>
decentralization goals.<br></blockquote><div><br></div><div>A one-time incr=
ease to 8MB is safer than a dynamically growing limit over time for exactly=
this reason. Admittedly whenever the next debate to increase the block siz=
e over 8MB happens it will be even more painful and non-obvious, but that i=
s the safety check to prevent unbounded block size increase.</div></div></d=
iv></div>
--001a11331df0c37d6e051c7b4c66--
|
