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
|
Return-Path: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0F45A2C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2017 18:19:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com
[209.85.213.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E33061D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2017 18:19:44 +0000 (UTC)
Received: by mail-vk0-f41.google.com with SMTP id k127so61486714vke.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 06 Feb 2017 10:19:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=1zMk0q5ENIEHOVC9z9GhHnyk0YdrZbtKplQnxe9QLJc=;
b=cC+xJdFUWQD8GFnPcMCaDOYZDXjzEhZ+Cc+5RJPKYiE/bqfrnz8B2UEEP1dTmim31R
unIkyoWl4arhukKjQFzfHuH8p4+UvjWitWF6YDIVfiaAvnS87zjcUQwx5Bj/uVK3ywFT
Occt77sDPUTD7s0+Z8jU3ZQwIaOrCYuAn4Ko5QCD8RgsuzkbhZlc+Lsarf+nXCh/elPx
ZDqnTi0Y4Q0zVNwkPTj2zFxn+1xg2TjnjVUELU7HepiTNBySBc5UIRPODAt6qWyZ6VWS
Iyr795+hycmB+sT+O1TUbSu3Q2jQPt9qeneF3YVfoS2EAAV4vX4Zni3Swz6UFNIU95C5
YjpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=1zMk0q5ENIEHOVC9z9GhHnyk0YdrZbtKplQnxe9QLJc=;
b=NqCTo+7Bqt6GrNlQ5hRveACs/lOTQq6U9rOyc66QnrSJl1P7vPuoV3X66U4OHfHch6
rg+iJHqfK0uYZej4g+/lQjfZIAmpkuxsNktMaaAA0APsLmVvQZ5yixe9EJn8EjB2Ssht
bZ3R7SWSHozzcbXsOwVwNHiskfTbk2eyGFWQ+S5Y008hEfEN9DO24pyJTx9FGWi9DNuE
vkPTbOEuJ9sM45CSE5yf6Dzmw0OZFNhFkdC8gusGaWGPNLbkyRd45SDxtJfg7WvAKwou
Acp1YAUnl1qqRDxAAHbQHSxVAsDfYaqVeHJDggGiYBy08SNUrwQe9YmtKShv/KiyGZhz
bvYA==
X-Gm-Message-State: AMke39kWyzuCXKMqmq/VjgvPqeronbILNdfp92FIwmJ7Kuji6nLF2zkCFE3wxsmf6/8pKCX7ciKEXa/E+R6h7A==
X-Received: by 10.31.142.68 with SMTP id q65mr5362018vkd.83.1486405183887;
Mon, 06 Feb 2017 10:19:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.77 with HTTP; Mon, 6 Feb 2017 10:19:43 -0800 (PST)
In-Reply-To: <201702052302.29599.luke@dashjr.org>
References: <ea63ed5a-4280-c063-4984-5bc8a4b2aafa@gmail.com>
<201702052302.29599.luke@dashjr.org>
From: "t. khan" <teekhan42@gmail.com>
Date: Mon, 6 Feb 2017 13:19:43 -0500
Message-ID: <CAGCNRJrNRb4Eo5T8+KsKnazOCm15g89RFLtRW07k1KjN6TpTDw@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1143703afa60ed0547e0ac53
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, HTML_OBFUSCATE_05_10, 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: Wed, 08 Feb 2017 01:43:26 +0000
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 18:19:46 -0000
--001a1143703afa60ed0547e0ac53
Content-Type: text/plain; charset=UTF-8
>My BIP draft didn't make progress because the community opposes any block
size
>increase hardfork ever.
Luke, how do you know the community opposes that? Specifically, how did you
come to this conclusion?
>Your version doesn't address the current block size
>issues (ie, the blocks being too large).
Why do you think blocks are "too large"? Please cite some evidence. I've
asked this before and you ignored it, but an answer would be helpful to the
discussion.
- t.k.
On Sun, Feb 5, 2017 at 6:02 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> My BIP draft didn't make progress because the community opposes any block
> size
> increase hardfork ever. Your version doesn't address the current block size
> issues (ie, the blocks being too large). 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.
>
> 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-blksize.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
>
--001a1143703afa60ed0547e0ac53
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>My BIP draft didn't make progress because the comm=
unity opposes any block size<br>>increase hardfork ever.<div><br></div><=
div>Luke, how do you know the community opposes that? Specifically, how did=
you come to this conclusion?</div><div><br></div><div>>Your version doe=
sn't address the current block size<br>>issues (ie, the blocks being=
too large).<br></div><div><br></div><div>Why do you think blocks are "=
;too large"? Please cite some evidence. I've asked this before and=
you ignored it, but an answer would be helpful to the discussion.</div><di=
v><br></div><div>- t.k.<br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Sun, Feb 5, 2017 at 6:02 PM, Luke Dashjr via bitcoin-dev <span=
dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex">My BIP draft didn't make progress because th=
e community opposes any block size<br>
increase hardfork ever. Your version doesn't address the current block =
size<br>
issues (ie, the blocks being too large). So you've retained the only ce=
rtain-<br>
DOA parts of my proposal, and removed the most useful part... I'm not s=
ure the<br>
point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sen=
se<br>
to keep the BIP 9 deployment at all - either it gets consensus or it doesn&=
#39;t,<br>
but miners have no part in deployment of it.<br>
<div class=3D"m_5478911187313260324gmail-HOEnZb"><div class=3D"m_5478911187=
313260324gmail-h5"><br>
On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:<br>
> Hello all,<br>
><br>
> Many people have expressed discontent with Luke-jr's proposed bloc=
k size<br>
> BIP, in particular with the decrease in size that would occur if it we=
re<br>
> to be activated prior to 2024.<br>
><br>
> I have decided to modify the proposal to instead begin the increase<br=
>
> steps at the current 1000000 byte limit. The increases and the time sp=
am<br>
> of each increase will remain the same, just that the increase begins<b=
r>
> from 1000000 bytes instead of 300000 bytes.<br>
><br>
> Furthermore, instead of a fixed schedule from a fixed point in time, t=
he<br>
> increases will instead be calculated off of the MTP of the activation<=
br>
> block (the first block to be in the active state for this fork).<br>
><br>
> While this proposal shares many of the same issues with the one it<br>
> modifies, I hope that it will be slightly less controversial and can<b=
r>
> allow us to move forward with scaling Bitcoin.<br>
><br>
> The full text of the proposal can be found at<br>
> <a href=3D"https://github.com/achow101/bips/blob/bip-blksize/bip-blksi=
ze.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/achow=
101/bi<wbr>ps/blob/bip-blksize/bip-blksiz<wbr>e.mediawiki</a>.<br>
> My implementation of it is available at<br>
> <a href=3D"https://github.com/achow101/bitcoin/tree/bip-blksize" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/achow101/bi<wbr>tcoin/=
tree/bip-blksize</a><br>
><br>
><br>
> Andrew<br>
><br>
> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div></div></div>
--001a1143703afa60ed0547e0ac53--
|
