Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.175 as permitted sender)
	client-ip=209.85.212.175; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f175.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <554BE0E1.5030001@bluematt.me>
References: <554BE0E1.5030001@bluematt.me>
Date: Fri, 8 May 2015 12:03:04 +0200
Message-ID: <CANEZrP3uKLvzKi-wXBJWL=pwqB+eAe3FbPjyESD52y5TGkg+Rg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=001a11c2a3a85bfc0305158f2236
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Precedence: list

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

>
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.


With a 20mb cap, miners still have the option of the soft limit.

I would actually be quite surprised if there were no point along the road
from 1mb to 20mb where miners felt a need to throttle their block sizes
artificially, for the exact reason you point out: propagation delays.

But we don't *need* to have fancy protocol upgrades implemented right now.
All we need is to demolish one bottleneck (the hard cap) so we can then
move on and demolish the next one (whatever that is, probably faster
propagation). Scaling is a series of walls we punch through as we encounter
them. One down, onto the next. We don't have to tackle them all
simultaneously.

FWIW I don't think the GFW just triggers packet loss, these days. It's
blocked port 8333 entirely.

 * I'd very much like to see someone working on better scaling
> technology ... I know StrawPay is working on development,
>

So this request is already satisfied, isn't it? As you point out, expecting
more at this stage in development is unreasonable, there's nothing for
anyone to experiment with or commit to.

They have code here, by the way:

   https://github.com/strawpay

You can find their fork of MultiBit HD, their implementation library, etc.
They've contributed patches and improvements to the payment channels code
we wrote.


>  * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
>

What are your thoughts on using assurance contracts to fund network
security?

I don't *know* if hashing assurance contracts (HACs) will work. But I don't
know they won't work either. And right now I'm pretty sure that plain old
fee pressure won't work. Demand doesn't outstrip supply forever - people
find substitutes.

--001a11c2a3a85bfc0305158f2236
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">=C2=A0* Though there are many proposals floating around which =
could<br>
significantly decrease block propagation latency, none of them are<br>
implemented today. </blockquote><div><br></div><div>With a 20mb cap, miners=
 still have the option of the soft limit.</div><div><br></div><div>I would =
actually be quite surprised if there were no point along the road from 1mb =
to 20mb where miners felt a need to throttle their block sizes artificially=
, for the exact reason you point out: propagation delays.</div><div><br></d=
iv><div>But we don&#39;t <i>need</i>=C2=A0to have fancy protocol upgrades i=
mplemented right now. All we need is to demolish one bottleneck (the hard c=
ap) so we can then move on and demolish the next one (whatever that is, pro=
bably faster propagation). Scaling is a series of walls we punch through as=
 we encounter them. One down, onto the next. We don&#39;t have to tackle th=
em all simultaneously.</div><div><br></div><div>FWIW I don&#39;t think the =
GFW just triggers packet loss, these days. It&#39;s blocked port 8333 entir=
ely.</div><div><br></div><blockquote 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;padding-left:1ex">=C2=A0* I&#39;d very much like to=
 see someone working on better scaling<br>
technology ...=C2=A0I know StrawPay is working on development,<br></blockqu=
ote><div><br></div><div>So this request is already satisfied, isn&#39;t it?=
 As you point out, expecting more at this stage in development is unreasona=
ble, there&#39;s nothing for anyone to experiment with or commit to.</div><=
div><br></div><div>They have code here, by the way:</div><div><br></div><di=
v>=C2=A0 =C2=A0<a href=3D"https://github.com/strawpay">https://github.com/s=
trawpay</a><br></div><div><br></div><div>You can find their fork of MultiBi=
t HD, their implementation library, etc. They&#39;ve contributed patches an=
d improvements to the payment channels code we wrote.</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(204,204,204);border-left-style:solid;=
padding-left:1ex">
=C2=A0* I&#39;d like to see some better conclusions to the discussion aroun=
d<br>
long-term incentives within the system.<br></blockquote><div><br></div><div=
>What are your thoughts on using assurance contracts to fund network securi=
ty?</div><div><br></div><div>I don&#39;t <i>know</i>=C2=A0if hashing assura=
nce contracts (HACs) will work. But I don&#39;t know they won&#39;t work ei=
ther. And right now I&#39;m pretty sure that plain old fee pressure won&#39=
;t work. Demand doesn&#39;t outstrip supply forever - people find substitut=
es.=C2=A0</div></div></div></div>

--001a11c2a3a85bfc0305158f2236--