Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.43 as permitted sender)
	client-ip=209.85.219.43; envelope-from=dscvlt@gmail.com;
	helo=mail-oa0-f43.google.com; 
MIME-Version: 1.0
In-Reply-To: <a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
References: <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
	<52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk>
	<CACh7GpFGEvR+_qArYCkgi7AW4coSeH741ob4hmBpj6G3MayNAQ@mail.gmail.com>
	<a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
Date: Tue, 22 Apr 2014 01:10:48 +0930
Message-ID: <CAOXABZrB0p3KzKhGaYQsgQ2TGMvg_A0cuOhQ956QPRBPrO_=qg@mail.gmail.com>
From: Ashley Holman <dscvlt@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0153764acf694d04f78f528a
Cc: bitcoin-development@lists.sourceforge.net,
	Jonathan Levin <jonathan.levin@sant.ox.ac.uk>
Subject: Re: [Bitcoin-development] Economics of information propagation
Precedence: list

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

On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <pete@petertodd.org> wrote:
>
> That is mistaken: you can't mine on top of just a block header, leaving
> small miners disadvantaged as they are earning no profit while they wait
> for the information to validate the block and update their UTXO sets. This
> results in the same problem as before, as the large pools who mine most
> blocks can validate either instantly - the self-mine case - or more quickly
> than the smaller miners.
>
>
Under the headers first scenario, wouldn't the full block still reach
everyone in the same time as it would under the current rules?  So the
small miner loses nothing in terms of updating their UTXO set, but gains an
early "heads up" alert that a new block is coming.  This allows them spend
the propagation time working more productively on an empty block in the new
chain rather than wasting time on an orphan.  It's true that it doesn't
solve the problem of larger pools vs smaller pools, but if it doesn't make
it any worse then headers-first propagation would be a net benefit to the
network since it removes the incentive to make small blocks.

--089e0153764acf694d04f78f528a
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">On M=
on, Apr 21, 2014 at 1:36 PM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span=
> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">


That is mistaken: you can&#39;t mine on top of just a block header, leaving=
 small miners disadvantaged as they are earning no profit while they wait f=
or the information to validate the block and update their UTXO sets. This r=
esults in the same problem as before, as the large pools who mine most bloc=
ks can validate either instantly - the self-mine case - or more quickly tha=
n the smaller miners.<br>


<br></blockquote><div>=C2=A0</div><div>Under the headers first scenario, wo=
uldn&#39;t the full block still reach everyone in the same time as it would=
 under the current rules? =C2=A0So the small miner loses nothing in terms o=
f updating their UTXO set, but gains an early &quot;heads up&quot; alert th=
at a new block is coming. =C2=A0This allows them spend the propagation time=
 working more productively on an empty block in the new chain rather than w=
asting time on an orphan. =C2=A0It&#39;s true that it doesn&#39;t solve the=
 problem of larger pools vs smaller pools, but if it doesn&#39;t make it an=
y worse then headers-first propagation would be a net benefit to the networ=
k since it removes the incentive to make small blocks.</div>
</div></div></div>

--089e0153764acf694d04f78f528a--