Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.53 as permitted sender)
	client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f53.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <53B714A8.1080603@codehalo.com>
References: <10566815.3CllqoMfON@momentum> <53B6DB38.7010709@jerviss.org>
	<CAC1+kJOSAoz_BBaFnv4u-Dng7Y4h2tqOHSFRfuKvY87eBR71Gw@mail.gmail.com>
	<53B714A8.1080603@codehalo.com>
Date: Sat, 5 Jul 2014 10:43:05 +0200
Message-ID: <CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Randi Joseph <randi@codehalo.com>
Content-Type: multipart/alternative; boundary=089e0115f46e11759e04fd6e3b4f
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ASIC-proof mining
Precedence: list

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

>
> Is it possible instead to allocate a portion of the reward to " a # of
> runner up(s)" even though the runner-up(s) block will be orphaned?
>

There's really no concept of a "runner up" because hashing is progress
free. It's unintuitive and often trips people up. There's no concept that
everyone is 95% of the way to finding a solution and then someone pips you
to the post. It's more like playing the lottery over and over again.
Doesn't matter how many times you did it before, the next time your chances
are the same.

A better concept is of rewarding "near miss" solutions which is what we
already do of course, via pools, which pay you for shares which don't quite
meet the difficulty target but almost do. So the question is how can we
implement pools which have this reward structure (which obviously works
well) without miners simultaneously giving up their right to block creation
either due to technical problems or sheer lazyness.

--089e0115f46e11759e04fd6e3b4f
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">Is it possible instead to allocate a portion of =
the reward to &quot; a # of<br>

runner up(s)&quot; even though the runner-up(s) block will be orphaned?<br>=
</blockquote><div><br></div><div>There&#39;s really no concept of a &quot;r=
unner up&quot; because hashing is progress free. It&#39;s unintuitive and o=
ften trips people up. There&#39;s no concept that everyone is 95% of the wa=
y to finding a solution and then someone pips you to the post. It&#39;s mor=
e like playing the lottery over and over again. Doesn&#39;t matter how many=
 times you did it before, the next time your chances are the same.</div>
<div><br></div><div>A better concept is of rewarding &quot;near miss&quot; =
solutions which is what we already do of course, via pools, which pay you f=
or shares which don&#39;t quite meet the difficulty target but almost do. S=
o the question is how can we implement pools which have this reward structu=
re (which obviously works well) without miners simultaneously giving up the=
ir right to block creation either due to technical problems or sheer lazyne=
ss.</div>
</div></div></div>

--089e0115f46e11759e04fd6e3b4f--