path: root/53/8856287115e98ecaf228b99676a744ce7402e9

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1YqI3M-00052x-9e
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 09:25:12 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.177 as permitted sender)
	client-ip=209.85.212.177; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f177.google.com; 
Received: from mail-wi0-f177.google.com ([209.85.212.177])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqI3K-0002F5-Hz
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 09:25:12 +0000
Received: by wief7 with SMTP id f7so9111264wie.0
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 07 May 2015 02:25:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.105.193 with SMTP id go1mr4738498wib.92.1430990704539;
	Thu, 07 May 2015 02:25:04 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.90.114 with HTTP; Thu, 7 May 2015 02:25:04 -0700 (PDT)
In-Reply-To: <554A91BE.6060105@bluematt.me>
References: <554A91BE.6060105@bluematt.me>
Date: Thu, 7 May 2015 11:25:04 +0200
X-Google-Sender-Auth: AY3fU2phLRIvyIfx90-jbiFoULA
Message-ID: <CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=f46d041828009efea905157a7c29
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: 1YqI3K-0002F5-Hz
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 09:25:12 -0000

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

Hey Matt,

OK, let's get started ....

However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>

Probably because this list is not a good place for making progress or
reaching decisions. Those are triggered by pull requests (sometimes).

If you're wondering "why now", that's probably my fault. A few days ago
Wladimir posted a release timeline. 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 the chain by the end of the winter
growth season. That seemed tight.

Wladimir did not reply to this email, unfortunately. Perhaps he would like
the issue to go away. It won't - if Bitcoin continues on its current growth
trends it *will* run out of capacity, almost certainly by some time next
year.

What we need to see right now is leadership and a plan, that fits in the
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?


> Long-term incentive compatibility requires that there be some fee
> pressure, and that blocks be relatively consistently full or very nearly
> full.


I disagree. When the money supply eventually dwindles I doubt it will be
fee pressure that funds mining, but as that's a long time in the future,
it's very hard to predict what might happen.


> What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> 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 nodes
they'd probably be used a lot more.


> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale.


I have two huge problems with this line of thinking.

Firstly, no, the "Bitcoin ecosystem" is not well funded. Blockstream might
be, but significant numbers of users are running programs developed by tiny
startups, or volunteers who don't have millions in venture capital to play
with.

Arm-twisting "the ecosystem" into developing complicated Rube Goldberg
machines in double quick time, just to keep the Bitcoin show on the road,
is in fact the opposite of decentralisation - it will effectively exclude
anyone who isn't able to raise large amounts of corporate funding from
writing code that uses the Bitcoin network. Decentralisation benefits from
simplicity, and bigger blocks are (in Gavin's words) "the simplest thing
that will work".

My second problem is the claim that everyone is playing pretend about
Bitcoin, except you guys. I would put it another way - I would say those
people are building products and getting users, by making reasonable
engineering tradeoffs and using systems that work. Yes, one day those
systems might have to change. That's the nature of scaling. It's the nature
of progress. But not today. Probably not tomorrow either.

What I would like to see from Blockstream is a counter-proposal. So far you
have made lots of vague comments that we all agree with - yes,
decentralisation is good, yes some block size limit must exist, if only
because computers are finite machines.

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
not 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 dates attached, and a strong chance of actually being deployed
in time.

--f46d041828009efea905157a7c29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Matt,<div><br></div><div>OK, let&#39;s get started ...=
.<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">However, there hasnt been any discussion on this<br>
mailing list in several years as far as I can tell.<br></blockquote><div><b=
r></div><div>Probably because this list is not a good place for making prog=
ress or reaching decisions. Those are triggered by pull requests (sometimes=
).</div><div><br></div><div>If you&#39;re wondering &quot;why now&quot;, th=
at&#39;s probably my fault. A few days ago Wladimir posted a release timeli=
ne. 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 the=
 chain by the end of the winter growth season. That seemed tight.</div><div=
><br></div><div>Wladimir did not reply to this email, unfortunately. Perhap=
s he would like the issue to go away. It won&#39;t - if Bitcoin continues o=
n its current growth trends it <i>will</i>=C2=A0run out of capacity, almost=
 certainly by some time next year.</div><div><br></div><div>What we need to=
 see right now is leadership and a plan, that fits in the available time wi=
ndow.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex">Certainly a consensus in this =
kind of=C2=A0technical community should be a basic requirement for any seri=
ous=C2=A0commitment to blocksize increase.<br></blockquote><div><br></div><=
div>I&#39;m afraid I have come to disagree. I no longer believe this commun=
ity can reach consensus on anything protocol related. Some of these argumen=
ts have dragged on for years. Consensus isn&#39;t even well defined - conse=
nsus of who? Anyone who shows up? And what happens when, inevitably, no con=
sensus is reached? Stasis forever?</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">=
Long-term incentive compatibility requires=C2=A0that there be some fee pres=
sure, and that blocks be relatively=C2=A0consistently full or very nearly f=
ull. </blockquote><div><br></div><div>I disagree. When the money supply eve=
ntually dwindles I doubt it will be fee pressure that funds mining, but as =
that&#39;s a long time in the future, it&#39;s very hard to predict what mi=
ght happen.</div><div>=C2=A0<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">What we see today ar=
e<br>
transactions enjoying next-block confirmations with nearly zero pressure<br=
>
to include any fee at all (though many do because it makes wallet code<br>
simpler).<br></blockquote><div><br></div><div>Many do because free transact=
ions are broken - the relay limiter means whether a free transaction actual=
ly makes it across the network or not is basically pot luck and there&#39;s=
 no way for a wallet to know, short of either trying it or actually receivi=
ng every single transaction and repeating the calculations. If free transac=
tions weren&#39;t broken for all non-full nodes they&#39;d probably be used=
 a lot more.</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">This allows the well-f=
unded Bitcoin ecosystem to continue building<br>
systems which rely on transactions moving quickly into blocks while<br>
pretending these systems scale.</blockquote><div><br></div><div>I have two =
huge problems with this line of thinking.</div><div><br></div><div>Firstly,=
 no, the &quot;Bitcoin ecosystem&quot; is not well funded. Blockstream migh=
t be, but significant numbers of users are running programs developed by ti=
ny startups, or volunteers who don&#39;t have millions in venture capital t=
o play with.=C2=A0</div><div><br></div><div>Arm-twisting &quot;the ecosyste=
m&quot; into developing complicated Rube Goldberg machines in double quick =
time, just to keep the Bitcoin show on the road, is in fact the opposite of=
 decentralisation - it will effectively exclude anyone who isn&#39;t able t=
o raise large amounts of corporate funding from writing code that uses the =
Bitcoin network. Decentralisation benefits from simplicity, and bigger bloc=
ks are (in Gavin&#39;s words) &quot;the simplest thing that will work&quot;=
.</div><div><br></div><div>My second problem is the claim that everyone is =
playing pretend about Bitcoin, except you guys. I would put it another way =
- I would say those people are building products and getting users, by maki=
ng reasonable engineering tradeoffs and using systems that work. Yes, one d=
ay those systems might have to change. That&#39;s the nature of scaling. It=
&#39;s the nature of progress. But not today. Probably not tomorrow either.=
</div><div><br></div><div>What I would like to see from Blockstream is a co=
unter-proposal. So far you have made lots of vague comments that we all agr=
ee with - yes, decentralisation is good, yes some block size limit must exi=
st, if only because computers are finite machines.=C2=A0</div><div><br></di=
v><div>What I don&#39;t see from you yet is a <b>specific and=C2=A0credible=
=C2=A0plan</b>=C2=A0that fits within the next 12 months and which allows Bi=
tcoin to keep growing. Not some vague handwave like &quot;let&#39;s all use=
 the Lightning network&quot; (which does not exist), or &quot;let&#39;s do =
more research&quot; (Gavin has done plenty of research), or &quot;but what =
about the risks&quot; (Bitcoin is full of risks). A plan, with dates attach=
ed, and a strong chance of actually being deployed in time.</div></div></di=
v></div></div>

--f46d041828009efea905157a7c29--