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
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
|
Return-Path: <achow101@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 77DDA9BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2017 21:00:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com
[209.85.216.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5649610C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2017 21:00:12 +0000 (UTC)
Received: by mail-qt0-f169.google.com with SMTP id v23so117112771qtb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 06 Feb 2017 13:00:12 -0800 (PST)
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; bh=2ETpVZBgAaGdO+yhwpCSO7S54o3nXpmC7yIbvwZmijE=;
b=JdtUXMuAH3jYwHdyqycig/Qo5F8ehCSMthmIOqn9E9D24YSLG5hxmbDSHkxqhkzEzH
kceBxHolSnqNVvg0eKpKwh+EU16s42cd1Pt5+TW0mx9HWFs4CQSQcBHganCTZ+kQV+Dg
eypjuAafxOAiCUQxbbqn6mhcp3V3u2W4KXvOIqAOhyNO/jD8Jl4yElQbG7Cii9kPNJ+7
DXcLR2bljbPT1n3BkjfHR0gqIzI/Qpn0Yfev+6G2xg8PQ2xLXuF8mhAOE37lfAlQzxd2
czH0fVdcPIUpiQBTPvXBiMyryi26GCeagy0zFTCbN5edATnnxbosIh4LvW496pfO1UXM
crUQ==
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;
bh=2ETpVZBgAaGdO+yhwpCSO7S54o3nXpmC7yIbvwZmijE=;
b=S358DetOGg/hoKi5iZaB5y/Jt3vD97nm4jyg8mjsrwXstZN2TbGk065P1Exh3IGjnH
AttIhoJWOyDorMbU5QF0M8LCKt01eK1yjYgUTIu9qDB3XrI3hB/g3041VsGAJKPIJSPC
l08us+NeFt4n4j657WQ29gfSJVkM2el96z1Z29q69HW8hMlag5mhG0xyeAJdjiwakSOv
9a4SbL+1L99avFChyijfi8H2lPdE9o1RBP8T6wb4+ChmF+rwsMaSgt7zNvpuUebkOU0s
CHRffVFO9BeRMnV0xVM9Z68pyY+rE5aPeg4CYnC94KDL3i7uqQ/DN9hSGvBlC0oVacnW
8Ngw==
X-Gm-Message-State: AMke39nFXjChRk8SfQzeE8xfoSAPuC98J2F2eTclxUQmgqNk29BS6qAzM2BgqDoqszJVIQ==
X-Received: by 10.200.37.183 with SMTP id e52mr11948701qte.166.1486414811155;
Mon, 06 Feb 2017 13:00:11 -0800 (PST)
Received: from [10.104.251.158] (129-2-180-254.wireless.umd.edu.
[129.2.180.254]) by smtp.gmail.com with ESMTPSA id
h124sm1484443qke.40.2017.02.06.13.00.09
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 06 Feb 2017 13:00:10 -0800 (PST)
To: Thomas Kerin <bitcoin.ml@thomaslerin.io>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <ea63ed5a-4280-c063-4984-5bc8a4b2aafa@gmail.com>
<201702052302.29599.luke@dashjr.org>
<03b80a7b-6c8c-cdff-1826-6535bef12993@gmail.com>
<C5621135-FBC8-44E7-9EC0-AFDEEBB6031E@thomaslerin.io>
From: Andrew C <achow101@gmail.com>
Message-ID: <a86a5d01-088f-5242-12ab-eea374858899@gmail.com>
Date: Mon, 6 Feb 2017 16:00:18 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <C5621135-FBC8-44E7-9EC0-AFDEEBB6031E@thomaslerin.io>
Content-Type: multipart/alternative;
boundary="------------C75D85E4A6999CF9BE9A44CB"
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, 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
Subject: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP
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: Mon, 06 Feb 2017 21:00:13 -0000
This is a multi-part message in MIME format.
--------------C75D85E4A6999CF9BE9A44CB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
I looked at the discussions about the block size and about Luke-Jr's
proposal on Reddit and Bitcointalk. From what I observed of all of the
discussions is that few users are in favor of the status quo, and even
fewer are in favor of decreasing the block size. The majority of users
favored Segwit because it was a block size increase (that was a commonly
used reason in support of it and in arguments about increasing the block
size).
Discussions about Luke-Jr's proposal indicated that many users disagreed
with the decrease in block size and the time that it took to increase
again to 1 MB. There was not only disagreement but explicit ridicule and
mocking of that aspect of the proposal.
On 2/6/2017 3:28 PM, Thomas Kerin wrote:
> "Many users are of the opposite opinion, that the block size is too
> small." - That is newspeak, the users can speak for themselves.
>
> From whom did you gather feedback from before you changed Luke-Jrs BIP?=
>
> If people don't agree with the proposal, changing it an infinite
> number of times light well lead to the same result.
>
> Have the users spoken, in their response to what Luke-Jr proposed?
>
> On 6 February 2017 00:53:03 CET, Andrew C via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 2/5/2017 6:02 PM, Luke Dashjr wrote:
>
> My BIP draft didn't make progress because the community
> opposes any block size increase hardfork ever.=20
>
> From what I have observed, it seems to be that people are more so
> opposed to a hard fork when there is a comparable soft fork availab=
le
> than simply opposed to any block size increase hard fork ever. From=
the
> various threads discussing your proposal, it seemed that many would=
> favor it if it increased over 1 MB sooner or if it never even decre=
ased
> in the first place.
>
> Your version doesn't address the current block size issues
> (ie, the blocks being too large).=20
>
> Many users are of the opposite opinion, that the block size is too
> small. I understand that the decrease is to allow the blockchain si=
ze to
> grow more slowly thereby allowing users to be more likely to run fu=
ll
> nodes. Unfortunately, I think that we are way past the point of no
> return on that. The blockchain is already 100+ GB. Decreasing the b=
lock
> size is not going to make that any smaller and is not going to make=
it
> any less painful to run a full node. Given that in order to start u=
p a
> new full node will still require downloading at least 100 GB of dat=
a, I
> don't think that decreasing the block size will better facilitate f=
ull
> node creation. Furthermore, the current trend with ISPs (at least i=
n the
> US) is implementing data and bandwidth caps so users are still unli=
kely
> to start up new full nodes regardless of any changes that we can
> currently do.
>
> So you've retained the only certain- DOA parts of my proposal,
> and removed the most useful part... I'm not sure the point.
> Also, your version is now EXCLUSIVELY a hardfork, so it makes
> no sense to keep the BIP 9 deployment at all - either it gets
> consensus or it doesn't, but miners have no part in deployment
> of it.=20
>
> Yes, I know deployment needs to be fixed. I was more proposing this=
for
> comment on the modified block size schedule. I just kept the deploy=
ment
> as it was originally. However, we could use a modified version of B=
IP 9
> by using one of the top three bits and a longer locked-in period as=
a
> grace period for all users to upgrade.
>
> On Sunday, February 05, 2017 9:50:26 PM Andrew C via
> bitcoin-dev wrote:
>
> Hello all, Many people have expressed discontent with
> Luke-jr's proposed block size BIP, in particular with the
> decrease in size that would occur if it were to be
> activated prior to 2024. I have decided to modify the
> proposal to instead begin the increase steps at the
> current 1000000 byte limit. The increases and the time
> spam of each increase will remain the same, just that the
> increase begins from 1000000 bytes instead of 300000
> bytes. Furthermore, instead of a fixed schedule from a
> fixed point in time, the increases will instead be
> calculated off of the MTP of the activation block (the
> first block to be in the active state for this fork).
> While this proposal shares many of the same issues with
> the one it modifies, I hope that it will be slightly less
> controversial and can allow us to move forward with
> scaling Bitcoin. The full text of the proposal can be
> found at
> https://github.com/achow101/bips/blob/bip-blksize/bip-blksi=
ze.mediawiki.
> My implementation of it is available at
> https://github.com/achow101/bitcoin/tree/bip-blksize Andrew=
> -----------------------------------------------------------=
-------------
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev
>
>
>
>
> -------------------------------------------------------------------=
-----
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.=
=20
--------------C75D85E4A6999CF9BE9A44CB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I looked at the discussions about the block size and about
Luke-Jr's proposal on Reddit and Bitcointalk. From what I observed
of all of the discussions is that few users are in favor of the
status quo, and even fewer are in favor of decreasing the block
size. The majority of users favored Segwit because it was a block
size increase (that was a commonly used reason in support of it
and in arguments about increasing the block size).</p>
<p>Discussions about Luke-Jr's proposal indicated that many users
disagreed with the decrease in block size and the time that it
took to increase again to 1 MB. There was not only disagreement
but explicit ridicule and mocking of that aspect of the proposal.<br>
</p>
<br>
<div class="moz-cite-prefix">On 2/6/2017 3:28 PM, Thomas Kerin
wrote:<br>
</div>
<blockquote
cite="mid:C5621135-FBC8-44E7-9EC0-AFDEEBB6031E@thomaslerin.io"
type="cite">"Many users are of the opposite opinion, that the
block size is too<br>
small." - That is newspeak, the users can speak for themselves. <br>
<br>
From whom did you gather feedback from before you changed Luke-Jrs
BIP? <br>
<br>
If people don't agree with the proposal, changing it an infinite
number of times light well lead to the same result. <br>
<br>
Have the users spoken, in their response to what Luke-Jr proposed?<br>
<br>
<div class="gmail_quote">On 6 February 2017 00:53:03 CET, Andrew C
via bitcoin-dev <a class="moz-txt-link-rfc2396E" href="mailto:bitcoin-dev@lists.linuxfoundation.org"><bitcoin-dev@lists.linuxfoundation.org></a>
wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<pre class="k9mail">
On 2/5/2017 6:02 PM, Luke Dashjr wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> My BIP draft didn't make progress because the community opposes any block size
increase hardfork ever.
</blockquote>From what I have observed, it seems to be that people are more so
opposed to a hard fork when there is a comparable soft fork available
than simply opposed to any block size increase hard fork ever. From the
various threads discussing your proposal, it seemed that many would
favor it if it increased over 1 MB sooner or if it never even decreased
in the first place.
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Your version doesn't address the current block size
issues (ie, the blocks being too large).
</blockquote>Many users are of the opposite opinion, that the block size is too
small. I understand that the decrease is to allow the blockchain size to
grow more slowly thereby allowing users to be more likely to run full
nodes. Unfortunately, I think that we are way past the point of no
return on that. The blockchain is already 100+ GB. Decreasing the block
size is not going to make that any smaller and is not going to make it
any less painful to run a full node. Given that in order to start up a
new full node will still require downloading at least 100 GB of data, I
don't think that decreasing the block size will better facilitate full
node creation. Furthermore, the current trend with ISPs (at least in the
US) is implementing data and bandwidth caps so users are still unlikely
to start up new full nodes regardless of any changes that we can
currently do.
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> So you've retained the only certain-
DOA parts of my proposal, and removed the most useful part... I'm not sure the
point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense
to keep the BIP 9 deployment at all - either it gets consensus or it doesn't,
but miners have no part in deployment of it.
</blockquote>Yes, I know deployment needs to be fixed. I was more proposing this for
comment on the modified block size schedule. I just kept the deployment
as it was originally. However, we could use a modified version of BIP 9
by using one of the top three bits and a longer locked-in period as a
grace period for all users to upgrade.
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">
On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Hello all,
Many people have expressed discontent with Luke-jr's proposed block size
BIP, in particular with the decrease in size that would occur if it were
to be activated prior to 2024.
I have decided to modify the proposal to instead begin the increase
steps at the current 1000000 byte limit. The increases and the time spam
of each increase will remain the same, just that the increase begins
from 1000000 bytes instead of 300000 bytes.
Furthermore, instead of a fixed schedule from a fixed point in time, the
increases will instead be calculated off of the MTP of the activation
block (the first block to be in the active state for this fork).
While this proposal shares many of the same issues with the one it
modifies, I hope that it will be slightly less controversial and can
allow us to move forward with scaling Bitcoin.
The full text of the proposal can be found at
<a moz-do-not-send="true" href="https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki">https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki</a>.
My implementation of it is available at
<a moz-do-not-send="true" href="https://github.com/achow101/bitcoin/tree/bip-blksize">https://github.com/achow101/bitcoin/tree/bip-blksize</a>
Andrew
<hr>
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a moz-do-not-send="true" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</blockquote></blockquote>
<hr>
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a moz-do-not-send="true" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre></blockquote></div>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
</blockquote>
</body></html>
--------------C75D85E4A6999CF9BE9A44CB--
|
