Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X42AU-0003p3-Ku for bitcoin-development@lists.sourceforge.net; Mon, 07 Jul 2014 06:12:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1X42AS-0001j3-PO for bitcoin-development@lists.sourceforge.net; Mon, 07 Jul 2014 06:12:50 +0000 Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 83E0F4B262; Sun, 6 Jul 2014 23:12:42 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla@fruiteater.riseup.net) with ESMTPSA id CA59EE60 Received: from localhost (127.0.0.1) (SquirrelMail authenticated user odinn.cyberguerrilla) by fruiteater.riseup.net with HTTP; Sun, 6 Jul 2014 23:12:42 -0700 Message-ID: <68ffba5f8bc28bb7a9c2f4f7f15ee683.squirrel@fruiteater.riseup.net> In-Reply-To: <53B9E7D6.2050703@codehalo.com> References: <10566815.3CllqoMfON@momentum> <53B6DB38.7010709@jerviss.org> <53B714A8.1080603@codehalo.com> <53B9E7D6.2050703@codehalo.com> Date: Sun, 6 Jul 2014 23:12:42 -0700 From: "Odinn Cyberguerrilla" To: "Randi Joseph" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.98.1 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.0 (--) 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Headers-End: 1X42AS-0001j3-PO 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: Mon, 07 Jul 2014 06:12:50 -0000 Just as an aside to this lengthy convo, the Cryptonote-based BCN recently had some interesting updates which made it easier for ordinary computers (nothing special) to handle it. I realize that's not Bitcoin, but I thought I'd throw it out there. > 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. > > -----------------------------------------------------------------------= ------- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community > Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft_________________________________________= ______ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >