public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Randi Joseph <randi@codehalo•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] ASIC-proof mining
Date: Sun, 06 Jul 2014 20:20:38 -0400	[thread overview]
Message-ID: <53B9E7D6.2050703@codehalo.com> (raw)
In-Reply-To: <CANEZrP3v3Racyt-b9_DLMKuQ8UMBkgEa8kfGmPjcSssmrDHkhA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

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.


[-- Attachment #2: Type: text/html, Size: 2329 bytes --]

  reply	other threads:[~2014-07-07  0:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04 10:27 Andy Parkins
2014-07-04 10:53 ` Alan Reiner
2014-07-04 11:08   ` Eugen Leitl
2014-07-04 11:15   ` Andy Parkins
2014-07-04 11:22     ` Alan Reiner
2014-07-04 11:28       ` Andy Parkins
2014-07-04 11:37 ` Gregory Maxwell
2014-07-04 12:01   ` Andy Parkins
2014-07-04 15:20     ` Mike Hearn
2014-07-04 16:50 ` kjj
2014-07-04 18:39   ` Ron Elliott
2014-07-04 19:54     ` Aaron Voisine
2014-07-04 20:21   ` Jorge Timón
2014-07-04 20:38     ` Luke Dashjr
2014-07-04 20:55     ` Randi Joseph
2014-07-05  8:43       ` Mike Hearn
2014-07-07  0:20         ` Randi Joseph [this message]
2014-07-07  6:12           ` Odinn Cyberguerrilla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B9E7D6.2050703@codehalo.com \
    --to=randi@codehalo$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=mike@plan99$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox