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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <btcdrak@gmail.com>) id 1Yyzem-0002bq-MQ
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 09:35:48 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.181 as permitted sender)
client-ip=209.85.212.181; envelope-from=btcdrak@gmail.com;
helo=mail-wi0-f181.google.com;
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yyzel-0005lO-75
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 09:35:48 +0000
Received: by wifw1 with SMTP id w1so70927032wif.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 31 May 2015 02:35:41 -0700 (PDT)
X-Received: by 10.180.86.73 with SMTP id n9mr10710377wiz.78.1433064941150;
Sun, 31 May 2015 02:35:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.136.196 with HTTP; Sun, 31 May 2015 02:35:20 -0700 (PDT)
In-Reply-To: <3698747.VeHb3lFFLZ@crushinator>
References: <3698747.VeHb3lFFLZ@crushinator>
From: Btc Drak <btcdrak@gmail.com>
Date: Sun, 31 May 2015 10:35:20 +0100
Message-ID: <CADJgMztZuqt1BM8S2W1nOOBET=na+L+SZe4RRPdLU4tnbA-7cA@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: multipart/alternative; boundary=f46d0442806ec1e6f005175d6e6c
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HK_RANDOM_FROM From username looks random
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.6 HK_RANDOM_ENVFROM Envelope sender username looks random
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(btcdrak[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yyzel-0005lO-75
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: A measured response to save
Bitcoin Core
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2015 09:35:48 -0000
--f46d0442806ec1e6f005175d6e6c
Content-Type: text/plain; charset=UTF-8
On Sun, May 31, 2015 at 1:29 AM, Matt Whitlock <bip@mattwhitlock.name>
wrote:
> 3. What *is* clear at this point is that Gavin will move ahead with his
> proposal, regardless of whether the remainder of the Bitcoin Core
> committers agree with him. If he has to commit his changes to Bitcoin XT
> and then rally the miners to switch, then that's what he'll do. He believes
> that he is working in the best interests of Bitcoin (as I would hope we all
> do), and so I do not fault him for his intentions. However, I think his
> proposal is too risky.
>
I seriously doubt if miners and merchants who's income depends on bitcoin
are going to risk a network split. Gavin isn't pedalling some mempool
policy which doesn't affect consensus. The changes have to be universally
adopted by miners and full nodes. If there is any uncertainty about that
global acceptance, those financially dependent on bitcoin will not take the
risk just to be political. You can see how conservative the mining
community is already by their slow upgrade of Bitcoin Core as it is. Even
if some miners and merchants generally support the idea of bigger blocks,
they most certainly are not going to take the risk of leading a hard fork
when there is substantial risk of it failing.
Until there is actual consensus among the technical community I wouldn't be
too concerned.
> 4. I also think that ignoring the immediate problem is too risky. If
> allowing significantly larger blocks will cause a serious problem for
> Bitcoin (which is a possibility that we cannot rule out, as we lack
> omniscience), then NOT making any change to Bitcoin Core will virtually
> *assure* that we cause exactly this problem, as the popular (non-technical)
> consensus appears to be in favor of Bitcoin XT and a larger block size
> limit. If we do nothing, then there's a very real chance that Bitcoin XT
> takes over, for better or worse.
>
I don't think anyone is ignoring the issues, nor that everyone accepts that
blocksize may have to eventually change. The overwhelming technical
majority do not agree there is a problem that needs to be immediately
addressed. It would be far more helpful if we focused on stuff that helps
enable level 2 technologies so that bitcoin can actually scale, (like
R/CLTV and malleability fixes which are being delayed by BIP66 rollout and
pending the new "concurrent soft-forks" proposal).
> 7. It's not a given that blocks will immediately expand to meet the hard
> limit. In fact, there are strong and compelling arguments why this will NOT
> happen. But in any software system, if a given scenario is *possible*, then
> one MUST assume that it will happen and must have a plan to handle it.
>
But of course it would be dealt with if and when it becomes necessary. It's
not like there is blanket opposition to increasing the blocksize ever, it's
the matter of if, when and how; but when is defintely not now.
9. My proposal is that we raise the block size limit *gradually*, using an
> approximately smooth function, without a step discontinuity. We can employ
> a linear growth function to adjust the block size limit *smoothly* from 1
> MB to 20 MB over the course of several years, beginning next March.
>
Automatic or dynamic blocksize increase risks being very difficult to shut
down if later we find it is negatively impacting the ecosystem... and
that's part of the reluctance with bigger blocks because we still have not
studied the potential downsides enough beyond some sketchy and disputed
calculations and overall it's not addressing scalability at all.
> 10. This is the difference between cannonballing into the deep end of the
> pool and walking gingerly down the steps into the shallow end. Both get you
> to the eventual goal, but one is reckless while the other is measured and
> deliberate. If there's a problem that larger blocks will enable, then I'd
> prefer to see the problem crop up gradually rather than all at once. If
> it's gradual, then we'll have time to discuss and fix it without panicking.
Extending blocksize now would be nothing more than a political move. I have
no idea what will be decided in the end, but I do know that in order for
bitcoin to survive, changes must be based on well thought out and discussed
technical merits and not the result of political pressure. Politics and
good software do not mix.
Drak
--f46d0442806ec1e6f005175d6e6c
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 S=
un, May 31, 2015 at 1:29 AM, Matt Whitlock <span dir=3D"ltr"><<a href=3D=
"mailto:bip@mattwhitlock.name" target=3D"_blank">bip@mattwhitlock.name</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex">3. What *is* clear at this point is t=
hat Gavin will move ahead with his proposal, regardless of whether the rema=
inder of the Bitcoin Core committers agree with him. If he has to commit hi=
s changes to Bitcoin XT and then rally the miners to switch, then that'=
s what he'll do. He believes that he is working in the best interests o=
f Bitcoin (as I would hope we all do), and so I do not fault him for his in=
tentions. However, I think his proposal is too risky.<br></blockquote><div>=
<br></div><div>I seriously doubt if miners and merchants who's income d=
epends on bitcoin are going to risk a network split. Gavin isn't pedall=
ing some mempool policy which doesn't affect consensus. The changes hav=
e to be universally adopted by miners and full nodes. If there is any uncer=
tainty about that global acceptance, those financially dependent on bitcoin=
will not take the risk just to be political. You can see how conservative =
the mining community is already by their slow upgrade of Bitcoin Core as it=
is. Even if some miners and merchants generally support the idea of bigger=
blocks, they most certainly are not going to take the risk of leading a ha=
rd fork when there is substantial risk of it failing.</div><div><br></div><=
div>Until there is actual consensus among the technical community I wouldn&=
#39;t be too concerned.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
4. I also think that ignoring the immediate problem is too risky. If allowi=
ng significantly larger blocks will cause a serious problem for Bitcoin (wh=
ich is a possibility that we cannot rule out, as we lack omniscience), then=
NOT making any change to Bitcoin Core will virtually *assure* that we caus=
e exactly this problem, as the popular (non-technical) consensus appears to=
be in favor of Bitcoin XT and a larger block size limit. If we do nothing,=
then there's a very real chance that Bitcoin XT takes over, for better=
or worse.<br></blockquote><div><br></div><div>I don't think anyone is =
ignoring the issues, nor that everyone accepts that blocksize may have to e=
ventually change. The overwhelming technical majority do not agree there is=
a problem that needs to be immediately addressed. It would be far more hel=
pful if we focused on stuff that helps enable level 2 technologies so that =
bitcoin can actually scale, (like R/CLTV and malleability fixes which are b=
eing delayed by BIP66 rollout and pending the new "concurrent soft-for=
ks" proposal).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex">7. It's not =
a given that blocks will immediately expand to meet the hard limit. In fact=
, there are strong and compelling arguments why this will NOT happen. But i=
n any software system, if a given scenario is *possible*, then one MUST ass=
ume that it will happen and must have a plan to handle it.<br></blockquote>=
<div><br></div><div>But of course it would be dealt with if and when it bec=
omes necessary. It's not like there is blanket opposition to increasing=
the blocksize ever, it's the matter of if, when and how; but when is d=
efintely not now.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex">9. My proposal is th=
at we raise the block size limit *gradually*, using an approximately smooth=
function, without a step discontinuity. We can employ a linear growth func=
tion to adjust the block size limit *smoothly* from 1 MB to 20 MB over the =
course of several years, beginning next March.<br></blockquote><div><br></d=
iv><div>Automatic or dynamic blocksize increase risks being very difficult =
to shut down if later we find it is negatively impacting the ecosystem... a=
nd that's part of the reluctance with bigger blocks because we still ha=
ve not studied the potential downsides enough beyond some sketchy and dispu=
ted calculations and overall it's not addressing scalability at all.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">
10. This is the difference between cannonballing into the deep end of the p=
ool and walking gingerly down the steps into the shallow end. Both get you =
to the eventual goal, but one is reckless while the other is measured and d=
eliberate. If there's a problem that larger blocks will enable, then I&=
#39;d prefer to see the problem crop up gradually rather than all at once. =
If it's gradual, then we'll have time to discuss and fix it without=
panicking.</blockquote><div><br></div><div>Extending blocksize now would b=
e nothing more than a political move. I have no idea what will be decided i=
n the end, but I do know that in order for bitcoin to survive, changes must=
be based on well thought out and discussed technical merits and not the re=
sult of political pressure. Politics and good software do not mix.</div><di=
v><br></div><div>Drak<br></div><div><br></div></div></div></div>
--f46d0442806ec1e6f005175d6e6c--
|
