From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X3LYu-0002u3-Ht for bitcoin-development@lists.sourceforge.net; Sat, 05 Jul 2014 08:43:12 +0000 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; Received: from mail-oa0-f53.google.com ([209.85.219.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X3LYt-0007vm-JO for bitcoin-development@lists.sourceforge.net; Sat, 05 Jul 2014 08:43:12 +0000 Received: by mail-oa0-f53.google.com with SMTP id l6so2578130oag.40 for ; Sat, 05 Jul 2014 01:43:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.97.230 with SMTP id ed6mr580930oeb.81.1404549786070; Sat, 05 Jul 2014 01:43:06 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.35.234 with HTTP; Sat, 5 Jul 2014 01:43:05 -0700 (PDT) In-Reply-To: <53B714A8.1080603@codehalo.com> References: <10566815.3CllqoMfON@momentum> <53B6DB38.7010709@jerviss.org> <53B714A8.1080603@codehalo.com> Date: Sat, 5 Jul 2014 10:43:05 +0200 X-Google-Sender-Auth: dX0gggW6nTk1b3OygPr4dBgaTsM Message-ID: From: Mike Hearn To: Randi Joseph Content-Type: multipart/alternative; boundary=089e0115f46e11759e04fd6e3b4f X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1X3LYt-0007vm-JO Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] ASIC-proof mining X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 08:43:12 -0000 --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
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 "r= unner up" because hashing is progress free. It's unintuitive and o= ften trips people up. There's no concept that everyone is 95% of the wa= y to finding a solution and then someone pips you to the post. It's mor= e 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 f= or shares which don'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.
--089e0115f46e11759e04fd6e3b4f--