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 --]
next prev parent 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 [Bitcoin-development] ASIC-proof mining 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.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=mike@plan99.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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