MIME-Version: 1.0
In-Reply-To: <trinity-4a084235-61c0-4c48-a4e2-eae912a67d8c-1437675155432@3capp-mailcom-bs03>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
	<CAPWm=eW8RgrG1CMEAMN4GeiMjZecFvNtZB_Y4rZNeofWSD0=Wg@mail.gmail.com>
	<CADm_WcYCUHs9Qe_T6WJOCUSK6stXYD8v6z5JcGHfRMURoOSFTA@mail.gmail.com>
	<CABm2gDq3JyZx0QCRDbcNSLSOBKdpi4h_7VN1XL8N42U38+eBAA@mail.gmail.com>
	<55B113AF.40500@thinlink.com>
	<CABsx9T1MTc-GmuQyFN1vaFK=CDWV_L214Pi9nR6jLMouQQD0fw@mail.gmail.com>
	<trinity-4a084235-61c0-4c48-a4e2-eae912a67d8c-1437675155432@3capp-mailcom-bs03>
Date: Thu, 23 Jul 2015 20:57:04 +0200
Message-ID: <CA+w+GKR3tuG4bhk+ArEF6OqPQOeO3kE-LPdg2u0bD4bYENq=5w@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Slurms MacKenzie <slurms@gmx.us>
Content-Type: multipart/alternative; boundary=001a113dd3d6082dcf051b8f7426
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list

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

>
> You complained about the lack of quantitative analysis being used, I gave
> it to you. There's nothing "negative" about displaying data which doesn't
> completely back up what your position is, I made a sensible conclusion
> based on the facts I have in front of me. Ignoring the information I
> collected and presented for you is incredibly childish.
>

He hasn't ignored you, and he wasn't responding to your email specifically
but rather the general attitude displayed in this forum for the last
several months (and I'd argue the last year or so).

Your data is interesting but ultimately tell us what we already know - that
the next bottleneck after the hard coded limit could easily be propagation
speed. The solution is likely to be a better protocol. Matt's custom
network already has optimised things, rolling some of those ideas into the
P2P protocol may be a good place to start, or something fancier like IBLTs.

Regardless, the *next* bottleneck is not the protocol, it's the hard cap.

So the conclusion remains unchanged: Bitcoin must grow, and solutions for
scaling it up will be found as the need arises.

--001a113dd3d6082dcf051b8f7426
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:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">You complained about the lack of quantitative an=
alysis being used, I gave it to you. There&#39;s nothing &quot;negative&quo=
t; about displaying data which doesn&#39;t completely back up what your pos=
ition is, I made a sensible conclusion based on the facts I have in front o=
f me. Ignoring the information I collected and presented for you is incredi=
bly childish.<br></blockquote><div><br></div><div>He hasn&#39;t ignored you=
, and he wasn&#39;t responding to your email specifically but rather the ge=
neral attitude displayed in this forum for the last several months (and I&#=
39;d argue the last year or so).</div><div><br></div><div>Your data is inte=
resting but ultimately tell us what we already know - that the next bottlen=
eck after the hard coded limit could easily be propagation speed. The solut=
ion is likely to be a better protocol. Matt&#39;s custom network already ha=
s optimised things, rolling some of those ideas into the P2P protocol may b=
e a good place to start, or something fancier like IBLTs.</div><div><br></d=
iv><div>Regardless, the <i>next</i>=C2=A0bottleneck is not the protocol, it=
&#39;s the hard cap.</div><div><br></div><div>So the conclusion remains unc=
hanged: Bitcoin must grow, and solutions for scaling it up will be found as=
 the need arises.</div></div></div></div>

--001a113dd3d6082dcf051b8f7426--