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
|
Return-Path: <kfriece@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C44D28CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 16:33:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com
[209.85.217.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F2DB16F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 16:33:15 +0000 (UTC)
Received: by lbbtg9 with SMTP id tg9so8212487lbb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Aug 2015 09:33:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=Q9jGgWSGLxcu/pXzIv3dKCys1H4NQ+EOMyipFmoH70s=;
b=DJbdz0xD1RRYTjG7rtecSrig7RNptZ4h/V/yD8eXPttiFgPy4LQZz70T/JKay4Z2YT
379x6ixWFp5748HLxbJYX981q9m86Oe4IR72WlQRDXRLhzgMky+rn5w1xEsTGPePbdG3
jhnLvxk3/fFv/gWU04dyRQgcynPWISHimoY7ytfzroG2+FJtlhgfj+7srmvq9InbosSw
Waz0qi5c4asHsNzUFaYbfM7nG7sRWXMFj89qejtycJolnEWMcVn5wfmU68mEzD5jYM4B
z/aIkjw4Dxl/h0+jImZSxRuXbuO0jgjzuMC8flkDMn61cUiULYrpXMeBDc87qagxxhsI
Stbw==
MIME-Version: 1.0
X-Received: by 10.112.164.74 with SMTP id yo10mr3189369lbb.124.1438878793386;
Thu, 06 Aug 2015 09:33:13 -0700 (PDT)
Received: by 10.25.145.199 with HTTP; Thu, 6 Aug 2015 09:33:13 -0700 (PDT)
Date: Thu, 6 Aug 2015 12:33:13 -0400
Message-ID: <CAKujSOFC+8DaGjpQ06iVkZGFUBnSs6fhW2aPFFJLXYoAJDbB2g@mail.gmail.com>
From: Ken Friece <kfriece@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c25ba25ad23e051ca713db
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,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
Subject: [bitcoin-dev] Analysis paralysis and the blocksize debate
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: Thu, 06 Aug 2015 16:33:16 -0000
--001a11c25ba25ad23e051ca713db
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I am a long time Bitcoin user, miner, investor, full node operator, and
distributed real-time system software engineer.
Out of the all currently proposed blocksize increase solutions, I support
BIP101 (or something like it) and find the current blocksize debate very
frustrating, so I will try to systematically debunk some common arguments
against BIP101 below.
1.
We should not increase the blocksize because we'll just end up hitting
the limit again at a future time.
-
If a reasonable blocksize increase like BIP101 that scales with
technology is implemented, it's not a given that we will hit the
blocksize
limit (consistently full blocks over an extended period of time) agai=
n in
the future. Stating that we will definitely hit the blocksize limit a=
gain
in the future is pure speculation about future bitcoin transaction vo=
lume
that can't possibly be known at this time, and is nothing but conject=
ure.
If technology increases faster than bitcoin transaction volume, simpl=
y
scaling the Bitcoin blocksize could keep up with future demand.
If Bitcoin
is successful beyond our wildest dreams and future transaction volume
outstrips future blockchain space, alternative solutions like
sidechains or
the lightning network will have more time to be implemented.
1.
The full node count will go down if we increase the blocksize because it
will be more costly to run a full node.
-
I'm not sure this is true. I currently run a full node on a higher
end consumer PC with a higher end home network connection, but if the
blocksize limit is not raised and transaction fees increase such
that it is
no longer economical for me to access the bitcoin blockchain directly=
, I
will no longer run a full node to support the network. Bitcoin
is no longer
interesting to me if it gets to the point where the average user
is priced
off the blockchain. Users that have direct access to the blockchain a=
re
more likely to run full nodes. If Bitcoin ever becomes purely a limit=
ed,
small settlement network, I will no longer support it and move onto
something else.
1.
The blocksize can only be increased if there is developer =E2=80=9Cconse=
nsus=E2=80=9D
and the change is not =E2=80=9Ccontroversial=E2=80=9D.
-
Any blocksize increase will the deemed =E2=80=9Ccontroversial=E2=80=
=9D and lack
=E2=80=9Cconsensus=E2=80=9D, but doing nothing in the face of consist=
ently full
blocks and
rising transaction fees is also =E2=80=9Ccontroversial=E2=80=9D and w=
ill lack
=E2=80=9Cconsensus=E2=80=9D.
Inaction, maintaining the status quo, and blocking a blocksize
increase in
the face of consistently full blocks and rising transaction fees
is just as
controversial as increasing the blocksize.
1.
Don't increase the blocksize now with all the promising work going on
with sidechains and the lightning network.
-
KISS (keep it simple, stupid). When dealing with a highly complex,
mission critical system, there needs to be a very compelling reason t=
o
choose a much more complex solution over a simple solution like BIP10=
1.
Sidechains and the lightning network are much more complex than
BIP101 and
introduce new points of failure. It's hard enough to get folks
to trust the
Bitcoin network after 7 years, so it will likely take years until
sidechains and the lightning network are proven enough to be trusted =
by
users.
1.
Some miners will be at a disadvantage with larger blocks.
-
As folks have pointed out multiple times, network speed is just one
of many variables that impact mining profitability. I don't believe f=
or a
second that every miner in China (57% of the network) would be negati=
vely
impacted by larger blocks because some of them either have decent net=
work
connections or connect to mining pools with decent network connection=
s.
Miners will be given ample notice of a blocksize increase before
it occurs,
so they will have time to make plans to deal with larger blocks. More
transactions per block should also increase miner profitability becau=
se
more transactions equals more users equals more transaction fees!
In conclusion, I think the next year is a make or break year for Bitcoin
and hope the developers do everything they can to come up with a reasonable
long term growth plan to put Bitcoin in the best possible position to be
successful.
--001a11c25ba25ad23e051ca713db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">
<p style=3D"margin-bottom:0in">I am a long time Bitcoin user, miner,
investor, full node operator, and distributed real-time system
software engineer.</p>
<p style=3D"margin-bottom:0in">Out of the all currently proposed
blocksize increase solutions, I support BIP101 (or something like it)
and find the current blocksize debate very frustrating, so I will try
to systematically debunk some common arguments against BIP101 below.</p>
<ol><li><p style=3D"margin-bottom:0in">We should not increase the
blocksize because we'll just end up hitting the limit again at a futur=
e time.</p>
</li></ol>
<ul><ul><li><p style=3D"margin-bottom:0in">If a reasonable blocksize
increase like BIP101 that scales with technology is implemented,
it's not a given that we will hit the blocksize limit (consistently
full blocks over an extended period of time) again in the future.
Stating that we will definitely hit the blocksize limit again in
the future is pure speculation about future bitcoin transaction
volume that can't possibly be known at this time, and is nothing but
conjecture. If technology increases faster than bitcoin transaction
volume, simply scaling the Bitcoin blocksize could keep up with
future demand. If Bitcoin is successful beyond our wildest dreams
and future transaction volume outstrips future blockchain space,
alternative solutions like sidechains or the lightning network will
have more time to be implemented.=20
</p></li></ul></ul>
<ol start=3D"2"><li><p style=3D"margin-bottom:0in">The full node count will=
go down
if we increase the blocksize because it will be more costly to run a
full node.</p></li></ol>
<ul><ul><li><p style=3D"margin-bottom:0in">I'm not sure this is true. I
currently run a full node on a higher end consumer PC with a higher
end home network connection, but if the blocksize limit is not
raised and transaction fees increase such that it is no longer
economical for me to access the bitcoin blockchain directly, I will
no longer run a full node to support the network. Bitcoin is no
longer interesting to me if it gets to the point where the average
user is priced off the blockchain. Users that have direct access to
the blockchain are more likely to run full nodes. If Bitcoin ever
becomes purely a limited, small settlement network, I will no
longer support it and move onto something else.</p>
</li></ul></ul>
<ol start=3D"3"><li><p style=3D"margin-bottom:0in">The blocksize can only b=
e
increased if there is developer =E2=80=9Cconsensus=E2=80=9D and the change=
is
not =E2=80=9Ccontroversial=E2=80=9D.</p>
=09
</li></ol>
<ul><ul><li><p style=3D"margin-bottom:0in">Any blocksize increase will the
deemed =E2=80=9Ccontroversial=E2=80=9D and lack =E2=80=9Cconsensus=E2=80=
=9D, but doing
nothing in the face of consistently full blocks and rising
transaction fees is also =E2=80=9Ccontroversial=E2=80=9D and will lack
=E2=80=9Cconsensus=E2=80=9D. Inaction, maintaining the status
quo, and blocking a blocksize increase in the face of consistently
full blocks and rising transaction fees is just as controversial as
increasing the blocksize.</p>
</li></ul></ul>
<ol start=3D"4"><li><p style=3D"margin-bottom:0in">Don't increase the b=
locksize now
with all the promising work going on with sidechains and the
lightning network.</p>
=09
</li></ol>
<ul><ul><li><p style=3D"margin-bottom:0in">KISS (keep it simple, stupid).
When dealing with a highly complex, mission critical system, there
needs to be a very compelling reason to choose a much more complex
solution over a simple solution like BIP101. Sidechains and the
lightning network are much more complex than BIP101 and introduce
new points of failure. It's hard enough to get folks to trust the
Bitcoin network after 7 years, so it will likely take years until
sidechains and the lightning network are proven enough to be
trusted by users.</p>
</li></ul></ul>
<ol start=3D"5"><li><p style=3D"margin-bottom:0in">Some miners will be at a
disadvantage with larger blocks.</p>
=09
</li></ol>
<ul><ul><li><p style=3D"margin-bottom:0in">As folks have pointed out
multiple times, network speed is just one of many variables that
impact mining profitability. I don't believe for a second that
every miner in China (57% of the network) would be negatively
impacted by larger blocks because some of them either have decent
network connections or connect to mining pools with decent network
connections. Miners will be given ample notice of a blocksize
increase before it occurs, so they will have time to make plans to
deal with larger blocks. More transactions per block should also
increase miner profitability because more transactions equals more
users equals more transaction fees!=20
</p>
</li></ul></ul>
<p style=3D"margin-bottom:0in">In conclusion, I think the next year is
a make or break year for Bitcoin and hope the developers do
everything they can to come up with a reasonable long term growth
plan to put Bitcoin in the best possible position to be successful.</p>
</div>
--001a11c25ba25ad23e051ca713db--
|
