path: root/3a/7136176eba6b76322394dd333455c0199cb197

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1YqK00-0002WP-BY
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 11:29:52 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.52 as permitted sender)
	client-ip=74.125.82.52; envelope-from=mh.in.england@gmail.com;
	helo=mail-wg0-f52.google.com; 
Received: from mail-wg0-f52.google.com ([74.125.82.52])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqJzy-00059R-Nr
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 11:29:52 +0000
Received: by wgiu9 with SMTP id u9so40288056wgi.3
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 07 May 2015 04:29:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.48.101 with SMTP id k5mr6414722wjn.79.1430998184713;
	Thu, 07 May 2015 04:29:44 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.90.114 with HTTP; Thu, 7 May 2015 04:29:44 -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 13:29:44 +0200
X-Google-Sender-Auth: NymG-xfGJQDKFkjeEa84SdL2LOI
Message-ID: <CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=047d7ba9791c79641705157c3ae9
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1YqJzy-00059R-Nr
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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:29:52 -0000

--047d7ba9791c79641705157c3ae9
Content-Type: text/plain; charset=UTF-8

>
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
>

I was referring to winter next year. 0.12 isn't scheduled until the end of
the year, according to Wladimir. I explained where this figure comes from
in this article:

https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab760d

It's a fairly simple estimate based on previous growth patterns.

Because I love wild guesses and mine is that full 1 MB blocks will not
> happen until June 2017.
>

OK, it could be. But do you think this debate will play out significantly
differently if you are right, I am wrong, and we have this discussion next
summer instead? Because in several years of watching these debates, I
haven't seen much change in them.


> We've successfully reached consensus for several softfork proposals
> already.
>

Are you sure about that?

What if Gavin popped up right now and said he disagreed with every current
proposal, he disagreed with side chains too, and there would be no
consensus on any of them until the block size limit was raised.

Would you say, oh, OK, guess that's it then. There's no consensus so might
as well scrap all those proposals, as they'll never happen anyway. Bye bye
side chains whitepaper.



> 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.
>

No. What I meant is that someone (theoretically Wladimir) needs to make a
clear decision. If that decision is "Bitcoin Core will wait and watch the
fireworks when blocks get full", that would be showing leadership .....
albeit I believe in the wrong direction. It would, however, let people know
what's what and let them start to make longer term plans.

This dillydallying around is an issue - people just make vague points that
can't really be disagreed with (more nodes would be nice, smaller pools
would also be nice etc), and nothing gets done.


> "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 never said Bitcoin is broken in the long term. Far from it - I laid out
my ideas for what will happen when the block subsidy dwindles years ago.

But yes, it's hard for me to care overly much about what happens 30 years
from now, for the same reason you probably care more about what happens
tomorrow than what happens after you are dead. The further into the future
you try and plan, the less likely your plans are to survive unscathed.


> 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.
>

I think I see one of the causes of disagreement now.

I will write more on the topic of what will happen if we hit the block size
limit soon, maybe this evening. I have some other tasks to do first.

Regardless, I don't believe we will get any useful data out of such an
event. I've seen distributed systems run out of capacity before. What will
happen instead is technological failure followed by rapid user abandonment
that pushes traffic back below the pressure threshold .... and those users
will most likely not come back any time soon.


> 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.
>

I disagree that'd be the outcome, but good, this is progress. Now we need
to hear something like that from Wladimir, or whoever has the final say
around here.

With respect to the fee market: I think it's fairer to say Gavin wants a
market to exist, and he also wants supply to be plentiful. 20mb limit
doesn't actually mean every block will be 20mb the day after, no more than
they're all 1mb today. Miners may discover that if they go beyond 5mb they
have too many orphans and then propagation speed will have to be optimised
to break through the next bottleneck. Scaling is always about finding the
next bottleneck and removing it, ideally, before you hit it.

--047d7ba9791c79641705157c3ae9
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"><blo=
ckquote 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;paddi=
ng-left:1ex">Can you please elaborate on what terrible things will happen i=
f we<br>
don&#39;t increase the block size by winter this year?<br></blockquote><div=
><br></div><div>I was referring to winter next year. 0.12 isn&#39;t schedul=
ed until the end of the year, according to Wladimir. I explained where this=
 figure comes from in this article:</div><div><br></div><div><a href=3D"htt=
ps://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab7=
60d">https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-3=
5733bab760d</a><br></div><div><br></div><div>It&#39;s a fairly simple estim=
ate based on previous growth patterns.</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
>Because I love wild guesses and mine is that full 1 MB blocks will not<br>
happen until June 2017.<br></blockquote><div><br></div><div>OK, it could be=
. But do you think this debate will play out significantly differently if y=
ou are right, I am wrong, and we have this discussion next summer instead? =
Because in several years of watching these debates, I haven&#39;t seen much=
 change in them.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=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">We&#39;ve successfu=
lly reached consensus for several softfork proposals already.<br></blockquo=
te><div><br></div><div>Are you sure about that?</div><div><br></div><div>Wh=
at if Gavin popped up right now and said he disagreed with every current pr=
oposal, he disagreed with side chains too, and there would be no consensus =
on any of them until the block size limit was raised.</div><div><br></div><=
div>Would you say, oh, OK, guess that&#39;s it then. There&#39;s no consens=
us so might as well scrap all those proposals, as they&#39;ll never happen =
anyway. Bye bye side chains whitepaper.</div><div><br></div><div>=C2=A0<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex">I just hope that by=C2=A0 &quot;What we need to see =
right now is leadership&quot; you<br>
don&#39;t mean something like &quot;when Gaving and Mike agree it&#39;s eno=
ugh to<br>
deploy a hardfork&quot; when you go from vague to concrete.<br></blockquote=
><div><br></div><div>No. What I meant is that someone (theoretically Wladim=
ir) needs to make a clear decision. If that decision is &quot;Bitcoin Core =
will wait and watch the fireworks when blocks get full&quot;, that would be=
 showing leadership ..... albeit I believe in the wrong direction. It would=
, however, let people know what&#39;s what and let them start to make longe=
r term plans.</div><div><br></div><div>This dillydallying around is an issu=
e - people just make vague points that can&#39;t really be disagreed with (=
more nodes would be nice, smaller pools would also be nice etc), and nothin=
g gets done.</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(20=
4,204,204);border-left-style:solid;padding-left:1ex">&quot;no bitcoin long =
term it&#39;s broken long term but that&#39;s far away in the<br>
future so let&#39;s just worry about the present&quot;.<br></blockquote><di=
v><br></div><div>I never said Bitcoin is broken in the long term. Far from =
it - I laid out my ideas for what will happen when the block subsidy dwindl=
es years ago.</div><div><br></div><div>But yes, it&#39;s hard for me to car=
e overly much about what happens 30 years from now, for the same reason you=
 probably care more about what happens tomorrow than what happens after you=
 are dead. The further into the future you try and plan, the less likely yo=
ur plans are to survive unscathed.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
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></=
blockquote><div><br></div><div>I think I see one of the causes of disagreem=
ent now.</div><div><br></div><div>I will write more on the topic of what wi=
ll happen if we hit the block size limit soon, maybe this evening. I have s=
ome other tasks to do first.</div><div><br></div><div>Regardless, I don&#39=
;t believe we will get any useful data out of such an event. I&#39;ve seen =
distributed systems run out of capacity before. What will happen instead is=
 technological failure followed by rapid user abandonment that pushes traff=
ic back below the pressure threshold .... and those users will most likely =
not come back any time soon.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Ok, thi=
s is my plan: we wait 12 months, hope that your estimations are<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></block=
quote><div><br></div><div>I disagree that&#39;d be the outcome, but good, t=
his is progress. Now we need to hear something like that from Wladimir, or =
whoever has the final say around here.</div><div>=C2=A0</div><div>With resp=
ect to the fee market: I think it&#39;s fairer to say Gavin wants a market =
to exist, and he also wants supply to be plentiful. 20mb limit doesn&#39;t =
actually mean every block will be 20mb the day after, no more than they&#39=
;re all 1mb today. Miners may discover that if they go beyond 5mb they have=
 too many orphans and then propagation speed will have to be optimised to b=
reak through the next bottleneck. Scaling is always about finding the next =
bottleneck and removing it, ideally, before you hit it.</div></div></div></=
div>

--047d7ba9791c79641705157c3ae9--