Message-ID: <53B9E7D6.2050703@codehalo.com>
Date: Sun, 06 Jul 2014 20:20:38 -0400
From: Randi Joseph <randi@codehalo.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
	rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Mike Hearn <mike@plan99.net>
References: <10566815.3CllqoMfON@momentum>	<53B6DB38.7010709@jerviss.org>	<CAC1+kJOSAoz_BBaFnv4u-Dng7Y4h2tqOHSFRfuKvY87eBR71Gw@mail.gmail.com>	<53B714A8.1080603@codehalo.com>
	<CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com>
In-Reply-To: <CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------010107020505020608000400"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ASIC-proof mining
Precedence: list

This is a multi-part message in MIME format.
--------------010107020505020608000400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks Mike.

Indeed, I am aware of current approach, which is why I was suggesting 
this as an alternative.
I haven't thought about it enough, and perhaps it was too radical a 
rethinking - just wanted to see what the smarter minds thought.

Thanks again.

-Randi

On 7/5/14, 4:43 AM, Mike Hearn wrote:
>
>     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.


--------------010107020505020608000400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Thanks Mike.<br>
      <br>
      Indeed, I am aware of current approach, which is why I was
      suggesting this as an alternative. <br>
      I haven't thought about it enough, and perhaps it was too radical
      a rethinking - just wanted to see what the smarter minds thought.<br>
      <br>
      Thanks again.<br>
      <br>
      -Randi<br>
      <br>
      On 7/5/14, 4:43 AM, Mike Hearn wrote:<br>
    </div>
    <blockquote
cite="mid:CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote">Is it possible instead to
              allocate a portion of the reward to " a # of<br>
              runner up(s)" even though the runner-up(s) block will be
              orphaned?<br>
            </blockquote>
            <div><br>
            </div>
            <div>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.</div>
            <div><br>
            </div>
            <div>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.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------010107020505020608000400--