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
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <akaramaoun@gmail.com>) id 1YqJmf-0001s5-49
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 11:16:05 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.171 as permitted sender)
client-ip=209.85.223.171; envelope-from=akaramaoun@gmail.com;
helo=mail-ie0-f171.google.com;
Received: from mail-ie0-f171.google.com ([209.85.223.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqJmd-0001Ul-5Y
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 11:16:05 +0000
Received: by iedfl3 with SMTP id fl3so40562309ied.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 04:15:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.43.196 with SMTP id y4mr3669950igl.14.1430997357794; Thu,
07 May 2015 04:15:57 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Thu, 7 May 2015 04:15:57 -0700 (PDT)
In-Reply-To: <CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
Date: Thu, 7 May 2015 11:15:57 +0000
X-Google-Sender-Auth: VrGbMIRbsuV9WmbWYxKpx40z3ps
Message-ID: <CAL8tG==YbM8Lv4+iW3PVO34Dcs_kJ7CMbw9koOSr7GpOYmbE=Q@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e011604122f9b6305157c091b
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(akaramaoun[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: 1YqJmd-0001Ul-5Y
Subject: Re: [Bitcoin-development] Block Size Increase
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: Thu, 07 May 2015 11:16:05 -0000
--089e011604122f9b6305157c091b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm mainly just an observer on this. I mostly agree with Pieter. Also, I
think the main reason why people like Gavin and Mike Hearn are trying to
rush this through is because they have some kind of "apps" that depend on
zero conf instant transactions, so this would of course require more
traffic on the blockchain. I think people like Gavin or Mike should state
clearly what kind of (rigorous) system for instant transactions is
satisfactory for use in their applications. Be it lightning or something
similar, what is good enough? And no zero conf is not a real secure system.
Then once we know what is good enough for them (and everyone else), we can
implement it as a soft fork into the protocol, and it's a win win situation
for both sides (we can also benefit from all the new users people like Mike
are trying bring in).
On Thu, May 7, 2015 at 10:52 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> On Thu, May 7, 2015 at 11:25 AM, Mike Hearn <mike@plan99.net> wrote:
> > I observed to Wladimir and Gavin in private that this timeline meant a
> change to the block size was unlikely to get into 0.11, leaving only 0.12=
,
> which would give everyone only a few months to upgrade in order to fork t=
he
> chain by the end of the winter growth season. That seemed tight.
>
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
> I assume that you are expecting full blocks by then, have you used any
> statistical technique to come up with that date or is it just your
> guess?
> Because I love wild guesses and mine is that full 1 MB blocks will not
> happen until June 2017.
>
> > What we need to see right now is leadership and a plan, that fits in th=
e
> > available time window.
> >
> >>
> >> Certainly a consensus in this kind of technical community should be a
> >> basic requirement for any serious commitment to blocksize increase.
> >
> >
> > I'm afraid I have come to disagree. I no longer believe this community
> can
> > reach consensus on anything protocol related. Some of these arguments
> have
> > dragged on for years. Consensus isn't even well defined - consensus of
> who?
> > Anyone who shows up? And what happens when, inevitably, no consensus is
> > reached? Stasis forever?
>
> We've successfully reached consensus for several softfork proposals
> already.
> I agree with others that hardfork need to be uncontroversial and there
> should be consensus about them.
> If you have other ideas for the criteria for hardfork deployment all I'm
> ears.
> I just hope that by "What we need to see right now is leadership" you
> don't mean something like "when Gaving and Mike agree it's enough to
> deploy a hardfork" when you go from vague to concrete.
>
>
> >> Long-term incentive compatibility requires that there be some fee
> >> pressure, and that blocks be relatively consistently full or very near=
ly
> >> full.
> >
> >
> > I disagree. When the money supply eventually dwindles I doubt it will b=
e
> fee
> > pressure that funds mining, but as that's a long time in the future, it=
's
> > very hard to predict what might happen.
>
> Oh, so your answer to "bitcoin will eventually need to live on fees
> and we would like to know more about how it will look like then" it's
> "no bitcoin long term it's broken long term but that's far away in the
> future so let's just worry about the present".
> I agree that it's hard to predict that future, but having some
> competition for block space would actually help us get more data on a
> similar situation to be able to predict that future better.
> What you want to avoid at all cost (the block size actually being
> used), I see as the best opportunity we have to look into the future.
>
> >> What we see today are
> >> transactions enjoying next-block confirmations with nearly zero pressu=
re
> >> to include any fee at all (though many do because it makes wallet code
> >> simpler).
> >
> >
> > Many do because free transactions are broken - the relay limiter means
> > whether a free transaction actually makes it across the network or not =
is
> > basically pot luck and there's no way for a wallet to know, short of
> either
> > trying it or actually receiving every single transaction and repeating
> the
> > calculations. If free transactions weren't broken for all non-full node=
s
> > they'd probably be used a lot more.
>
> Free transactions are a gift from miners that run an altruistic policy.
> That's great but we shouldn't rely on them for the future. They will
> likely disappear at some point and that's ok.
> In any case, he's not complaining about the lack of free transactions,
> more like the opposite.
> He is saying that's very easy to get free transactions in the next
> block and blocks aren't full so there's no incentive to include fees
> to compete for the space.
> We can talk a lot about "a fee market" and build a theoretically
> perfect fee estimator but we won't actually have a fee market until
> there's some competition for space.
> Nobody will pay for space that's abundant just like people don't pay
> for the air they breath.
>
> > What I don't see from you yet is a specific and credible plan that fits
> > within the next 12 months and which allows Bitcoin to keep growing. Not
> some
> > vague handwave like "let's all use the Lightning network" (which does n=
ot
> > exist), or "let's do more research" (Gavin has done plenty of research)=
,
> or
> > "but what about the risks" (Bitcoin is full of risks). A plan, with dat=
es
> > attached, and a strong chance of actually being deployed in time.
>
> Ok, this is my plan: we wait 12 months, hope that your estimations are
> correct (in case that my guess was better than yours, we keep waiting
> until June 2017) and start having full blocks and people having to
> wait 2 blocks for their transactions to be confirmed some times.
> That would be the beginning of a true "fee market", something that
> Gavin used to say was his #1 priority not so long ago (which seems
> contradictory with his current efforts to avoid that from happening).
> Having a true fee market seems clearly an advantage.
> What are supposedly disastrous negative parts of this plan that make
> an alternative plan (ie: increasing the block size) so necessary and
> obvious.
> I think the advocates of the size increase are failing to explain the
> disadvantages of maintaining the current size. It feels like the
> explanation are missing because it should be somehow obvious how the
> sky will burn if we don't increase the block size soon.
> But, well, it is not obvious to me, so please elaborate on why having
> a fee market (instead of just an price estimator for a market that
> doesn't even really exist) would be a disaster.
>
>
> -------------------------------------------------------------------------=
-----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--=20
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
--089e011604122f9b6305157c091b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm mainly just an observer on this. I mostly agree wi=
th Pieter. Also, I think the main reason why people like Gavin and Mike Hea=
rn are trying to rush this through is because they have some kind of "=
apps" that depend on zero conf instant transactions, so this would of =
course require more traffic on the blockchain. I think people like Gavin or=
Mike should state clearly what kind of (rigorous) system for instant trans=
actions is satisfactory for use in their applications. Be it lightning or s=
omething similar, what is good enough? And no zero conf is not a real secur=
e system. Then once we know what is good enough for them (and everyone else=
), we can implement it as a soft fork into the protocol, and it's a win=
win situation for both sides (we can also benefit from all the new users p=
eople like Mike are trying bring in).<br></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Thu, May 7, 2015 at 10:52 AM, Jorge Tim=C3=
=B3n <span dir=3D"ltr"><<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_b=
lank">jtimon@jtimon.cc</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span class=3D"">On Thu, May 7, 2015 at 11:25 AM, Mike Hearn <<a hre=
f=3D"mailto:mike@plan99.net">mike@plan99.net</a>> wrote:<br>
> I observed to Wladimir and Gavin in private that this timeline meant a=
change to the block size was unlikely to get into 0.11, leaving only 0.12,=
which would give everyone only a few months to upgrade in order to fork th=
e chain by the end of the winter growth season. That seemed tight.<br>
<br>
</span>Can you please elaborate on what terrible things will happen if we<b=
r>
don't increase the block size by winter this year?<br>
I assume that you are expecting full blocks by then, have you used any<br>
statistical technique to come up with that date or is it just your<br>
guess?<br>
Because I love wild guesses and mine is that full 1 MB blocks will not<br>
happen until June 2017.<br>
<span class=3D""><br>
> What we need to see right now is leadership and a plan, that fits in t=
he<br>
> available time window.<br>
><br>
>><br>
>> Certainly a consensus in this kind of technical community should b=
e a<br>
>> basic requirement for any serious commitment to blocksize increase=
.<br>
><br>
><br>
> I'm afraid I have come to disagree. I no longer believe this commu=
nity can<br>
> reach consensus on anything protocol related. Some of these arguments =
have<br>
> dragged on for years. Consensus isn't even well defined - consensu=
s of who?<br>
> Anyone who shows up? And what happens when, inevitably, no consensus i=
s<br>
> reached? Stasis forever?<br>
<br>
</span>We've successfully reached consensus for several softfork propos=
als already.<br>
I agree with others that hardfork need to be uncontroversial and there<br>
should be consensus about them.<br>
If you have other ideas for the criteria for hardfork deployment all I'=
m ears.<br>
I just hope that by=C2=A0 "What we need to see right now is leadership=
" you<br>
don't mean something like "when Gaving and Mike agree it's eno=
ugh to<br>
deploy a hardfork" when you go from vague to concrete.<br>
<span class=3D""><br>
<br>
>> Long-term incentive compatibility requires that there be some fee<=
br>
>> pressure, and that blocks be relatively consistently full or very =
nearly<br>
>> full.<br>
><br>
><br>
> I disagree. When the money supply eventually dwindles I doubt it will =
be fee<br>
> pressure that funds mining, but as that's a long time in the futur=
e, it's<br>
> very hard to predict what might happen.<br>
<br>
</span>Oh, so your answer to "bitcoin will eventually need to live on =
fees<br>
and we would like to know more about how it will look like then" it=
9;s<br>
"no bitcoin long term it's broken long term but that's far awa=
y in the<br>
future so let's just worry about the present".<br>
I agree that it's hard to predict that future, but having some<br>
competition for block space would actually help us get more data on a<br>
similar situation to be able to predict that future better.<br>
What you want to avoid at all cost (the block size actually being<br>
used), I see as the best opportunity we have to look into the future.<br>
<span class=3D""><br>
>> What we see today are<br>
>> transactions enjoying next-block confirmations with nearly zero pr=
essure<br>
>> to include any fee at all (though many do because it makes wallet =
code<br>
>> simpler).<br>
><br>
><br>
> Many do because free transactions are broken - the relay limiter means=
<br>
> whether a free transaction actually makes it across the network or not=
is<br>
> basically pot luck and there's no way for a wallet to know, short =
of either<br>
> trying it or actually receiving every single transaction and repeating=
the<br>
> calculations. If free transactions weren't broken for all non-full=
nodes<br>
> they'd probably be used a lot more.<br>
<br>
</span>Free transactions are a gift from miners that run an altruistic poli=
cy.<br>
That's great but we shouldn't rely on them for the future. They wil=
l<br>
likely disappear at some point and that's ok.<br>
In any case, he's not complaining about the lack of free transactions,<=
br>
more like the opposite.<br>
He is saying that's very easy to get free transactions in the next<br>
block and blocks aren't full so there's no incentive to include fee=
s<br>
to compete for the space.<br>
We can talk a lot about "a fee market" and build a theoretically<=
br>
perfect fee estimator but we won't actually have a fee market until<br>
there's some competition for space.<br>
Nobody will pay for space that's abundant just like people don't pa=
y<br>
for the air they breath.<br>
<span class=3D""><br>
> What I don't see from you yet is a specific and credible plan that=
fits<br>
> within the next 12 months and which allows Bitcoin to keep growing. No=
t some<br>
> vague handwave like "let's all use the Lightning network"=
; (which does not<br>
> exist), or "let's do more research" (Gavin has done plen=
ty of research), or<br>
> "but what about the risks" (Bitcoin is full of risks). A pla=
n, with dates<br>
> attached, and a strong chance of actually being deployed in time.<br>
<br>
</span>Ok, this is my plan: we wait 12 months, hope that your estimations a=
re<br>
correct (in case that my guess was better than yours, we keep waiting<br>
until June 2017) and start having full blocks and people having to<br>
wait 2 blocks for their transactions to be confirmed some times.<br>
That would be the beginning of a true "fee market", something tha=
t<br>
Gavin used to say was his #1 priority not so long ago (which seems<br>
contradictory with his current efforts to avoid that from happening).<br>
Having a true fee market seems clearly an advantage.<br>
What are supposedly disastrous negative parts of this plan that make<br>
an alternative plan (ie: increasing the block size) so necessary and<br>
obvious.<br>
I think the advocates of the size increase are failing to explain the<br>
disadvantages of maintaining the current size. It feels like the<br>
explanation are missing because it should be somehow obvious how the<br>
sky will burn if we don't increase the block size soon.<br>
But, well, it is not obvious to me, so please elaborate on why having<br>
a fee market (instead of just an price estimator for a market that<br>
doesn't even really exist) would be a disaster.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53=
B 5647</div>
</div>
--089e011604122f9b6305157c091b--
|