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
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
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 40A603C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Aug 2015 20:45:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
[209.85.213.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 14C9E8F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Aug 2015 20:45:25 +0000 (UTC)
Received: by iggf3 with SMTP id f3so35821921igg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 01 Aug 2015 13:45:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=AJ3P3kJNzXtvtCOYB+yN4PTbVM6c/M66QXWIqGZVzWo=;
b=tQ5euS6kE6qx351KqRsJdK2lvkq2UiitIpeDgu9KgtjWjWGFghfwtme+VNuf3E9pD+
f8nwqXvH2CVVvNWsLjKlaKeeCiVTQZ0ozqCAd8ZanvtPr18abSLp84kV3TUWQAL89OUQ
nZsNdZaVEix3rmXR3o4t2YaHUZmORHjUpkHzKottLSDtbC3fa5/hHUGOiApLtygNGgN/
kRR/gkE6oOTm2b1IU+ZXkWSraYU6DmHRnx0q2hUnovADKaHEUKMYNFuvXCbmb+X9P1K9
XU4uwTqcoKRrX/R1OJCTJkbYDvdl8foTExD0GVEY4tRZObkmfX/uQUPGAf3/j3ve//bK
b7RA==
MIME-Version: 1.0
X-Received: by 10.50.21.10 with SMTP id r10mr15052494ige.94.1438461924507;
Sat, 01 Aug 2015 13:45:24 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Sat, 1 Aug 2015 13:45:24 -0700 (PDT)
In-Reply-To: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
Date: Sat, 1 Aug 2015 22:45:24 +0200
Message-ID: <CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=047d7b86eeae0889da051c46047b
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@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal
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: Sat, 01 Aug 2015 20:45:26 -0000
--047d7b86eeae0889da051c46047b
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> There is a summary of the proposals in my previous mail at
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
> 1. Initiation: BIP34 style voting, with support of 750 out of the last
> 1000 blocks. The "hardfork bit" mechanism might be used:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
>
This is fine, I think. I believe we shouldn't proceed with a hardfork
without having reasonable expectation that it will be deployed by everyone
in time, while we can only measure miner acceptance. Still, as a
belt-and-suspenders this won't hurt.
> 2. Starting date: 30 days after 75% miner support, but not before
> 2016-01-12 00:00 UTC
>
> Rationale: A 30-day grace period is given to make sure everyone has enough
> time to follow. This is a compromise between 14 day in BIP101 and 1 year in
> BIP103. I tend to agree with BIP101. Even 1 year is given, people will just
> do it on the 364th day if they opt to procrastinate.
>
Given the time recent softforks have taken to deploy, I think that's too
soon.
2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in China.
> Most pool operators and devs should be back from new year holiday and not
> sleeping. (If the initiation is delayed, we may require that it must be UTC
> Tuesday midnight).
>
That's an interesting thing to take into account.
> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by
> 1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on
> 2017-05-11.
>
> Rationale: Instead of jumping to 8MB, I suggest to increase it gradually
> to 8MB in 16 months. 8MB should not be particularly painful to run even
> with current equipment (you may see my earlier post on bitctointalk:
> https://bitcointalk.org/index.php?topic=1054482.0). 8MB is also agreed by
> Chinese miners, who control >60% of the network.
>
I have considered suggesting a faster ramp-up in the beginning, but I don't
think there is indisputable evidence that we can currently deal with
significantly larger blocks. I don't think "painful" is the right criterion
either; I'm sure my equipment can "handle" 20 MB blocks too, but with a
huge impact on network propagation speed, and even more people choosing the
outsource their full nodes.
Regarding "reasonable", I have a theory. What if we would have had 8 MB
blocks from the start? My guess is that some more people would have decided
to run their high-transaction-rate use cases on chain, that we'd regularly
see 4-6 MB blocks, there would be more complaints about low full node
counts, maybe 90% instead of 60% of the hash rate would be have SPV mining
agreements with each other, we'd somehow have accepted that even worse
reality, but people would still be complaining about the measly 25
transactions per second that Bitcoin could handle on-chain, and be
demanding a faster rampup to a more "reasonable" 64 MB block size as well.
>
> 4. After 8MB is reached, the block size will be increased by 6.714% every
> 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or
> double every 2.9 years, or +27.67% per year. Stop growth at 4096MB on
> 2042-11-17.
>
> Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%
> p.a. of BIP101. This will take us almost 8 years from now just to go back
> to the original 32MB size (4 years for BIP101 and 22 years for BIP103)
>
> SSD price is expected to drop by >50%/year in the coming years. In 2020,
> we will only need to pay 2% of current price for SSD. 98% price reduction
> is enough for 40 years of 27.67% growth.
> Source:
> http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures
>
I know many technologies have had faster growth, but I believe that global
bandwidth accessibility is the bottleneck, so the growth rate in my
proposal is based on that.
> Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%
> should be safe at least for the coming 10 years.
> Source:
> https://www.telegeography.com/research-services/global-bandwidth-forecast-service/
>
I'd rather be conservative here. My primary purpose is trying to create an
uncontroversial proposal that introduces an expectation of growth with
technology.
--
Pieter
--047d7b86eeae0889da051c46047b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <=
span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> w=
rote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">There is a summary of the proposals in my previous mail =
at <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-=
July/009808.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2015-July/009808.html</a><br>
1. Initiation: BIP34 style voting, with support of 750 out of the last 1000=
blocks. The "hardfork bit" mechanism might be used: <a href=3D"h=
ttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html=
" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2015-July/009576.html</a><br></blockquote><div><br></div=
><div>This is fine, I think. I believe we shouldn't proceed with a hard=
fork without having reasonable expectation that it will be deployed by ever=
yone in time, while we can only measure miner acceptance. Still, as a belt-=
and-suspenders this won't hurt.<br>=C2=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
2. Starting date: 30 days after 75% miner support, but not before 2016-01-1=
2 00:00 UTC<br>
<br>
Rationale: A 30-day grace period is given to make sure everyone has enough =
time to follow. This is a compromise between 14 day in BIP101 and 1 year in=
BIP103. I tend to agree with BIP101. Even 1 year is given, people will jus=
t do it on the 364th day if they opt to procrastinate.<br></blockquote><div=
><br></div><div>Given the time recent softforks have taken to deploy, I thi=
nk that's too soon.<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in China. =
Most pool operators and devs should be back from new year holiday and not s=
leeping. (If the initiation is delayed, we may require that it must be UTC =
Tuesday midnight).<br></blockquote><div><br></div><div>That's an intere=
sting thing to take into account. <br></div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by =
1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on 20=
17-05-11.<br>
<br>
Rationale: Instead of jumping to 8MB, I suggest to increase it gradually to=
8MB in 16 months. 8MB should not be particularly painful to run even with =
current equipment (you may see my earlier post on bitctointalk: <a href=3D"=
https://bitcointalk.org/index.php?topic=3D1054482.0" rel=3D"noreferrer" tar=
get=3D"_blank">https://bitcointalk.org/index.php?topic=3D1054482.0</a>). 8M=
B is also agreed by Chinese miners, who control >60% of the network.<br>=
</blockquote><div><br></div><div>I have considered suggesting a faster ramp=
-up in the beginning, but I don't think there is indisputable evidence =
that we can currently deal with significantly larger blocks. I don't th=
ink "painful" is the right criterion either; I'm sure my equi=
pment can "handle" 20 MB blocks too, but with a huge impact on ne=
twork propagation speed, and even more people choosing the outsource their =
full nodes.<br><br></div><div>Regarding "reasonable", I have a th=
eory. What if we would have had 8 MB blocks from the start? My guess is tha=
t some more people would have decided to run their high-transaction-rate us=
e cases on chain, that we'd regularly see 4-6 MB blocks, there would be=
more complaints about low full node counts, maybe 90% instead of 60% of th=
e hash rate would be have SPV mining agreements with each other, we'd s=
omehow have accepted that even worse reality, but people would still be com=
plaining about the measly 25 transactions per second that Bitcoin could han=
dle on-chain, and be demanding a faster rampup to a more "reasonable&q=
uot; 64 MB block size as well.<br></div>=C2=A0<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
4. After 8MB is reached, the block size will be increased by 6.714% every 9=
7 days, which is equivalent to exactly octuple (8x) every 8.5 years, or dou=
ble every 2.9 years, or +27.67% per year. Stop growth at 4096MB on 2042-11-=
17.<br>
<br>
Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4% p.a.=
of BIP101. This will take us almost 8 years from now just to go back to th=
e original 32MB size (4 years for BIP101 and 22 years for BIP103)<br>
<br>
SSD price is expected to drop by >50%/year in the coming years. In 2020,=
we will only need to pay 2% of current price for SSD. 98% price reduction =
is enough for 40 years of 27.67% growth.<br>
Source: <a href=3D"http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_A=
rchitectures" rel=3D"noreferrer" target=3D"_blank">http://wikibon.org/wiki/=
v/Evolution_of_All-Flash_Array_Architectures</a><br></blockquote><div><br><=
/div><div>I know many technologies have had faster growth, but I believe th=
at global bandwidth accessibility is the bottleneck, so the growth rate in =
my proposal is based on that.<br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
Global bandwidth is expected to grow by 37%/year until 2021 so 27.67% shoul=
d be safe at least for the coming 10 years.<br>
Source: <a href=3D"https://www.telegeography.com/research-services/global-b=
andwidth-forecast-service/" rel=3D"noreferrer" target=3D"_blank">https://ww=
w.telegeography.com/research-services/global-bandwidth-forecast-service/</a=
><br></blockquote><div><br></div><div>I'd rather be conservative here. =
My primary purpose is trying to create an uncontroversial proposal that int=
roduces an expectation of growth with technology.<br><br>-- <br></div><div>=
Pieter<br><br></div></div></div></div>
--047d7b86eeae0889da051c46047b--
|
