From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X31bA-0006Sc-Ov for bitcoin-development@lists.sourceforge.net; Fri, 04 Jul 2014 11:24:12 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of leitl.org designates 164.177.174.8 as permitted sender) client-ip=164.177.174.8; envelope-from=eugen@leitl.org; helo=leitl.org; Received: from v8.ativel.com ([164.177.174.8] helo=leitl.org) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1X31b9-00072Q-1P for bitcoin-development@lists.sourceforge.net; Fri, 04 Jul 2014 11:24:12 +0000 Received: by leitl.org (Postfix, from userid 1000) id 20595540F7F; Fri, 4 Jul 2014 13:08:34 +0200 (CEST) Date: Fri, 4 Jul 2014 13:08:34 +0200 From: Eugen Leitl To: bitcoin-development@lists.sourceforge.net Message-ID: <20140704110833.GM26986@leitl.org> References: <10566815.3CllqoMfON@momentum> <53B687BB.9010103@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B687BB.9010103@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -1.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 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1X31b9-00072Q-1P 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: Fri, 04 Jul 2014 11:24:12 -0000 On Fri, Jul 04, 2014 at 06:53:47AM -0400, Alan Reiner wrote: > Something similar could be applied to your idea. We use the hash of a > prevBlockHash||nonce as the starting point for 1,000,000 lookup > operations. The output of the previous lookup is used to determine > which block and tx (perhaps which chunk of 32 bytes within that tx) is > used for the next lookup operation. This means that in order to do the > hashing, you need the entire blockchain available to you, even though > you'll only be using a small fraction of it for each "hash". This might > achieve what you're describing without actually requiring the full 20 GB > of reading on ever hash. Anything involving lots of unpredictable memory accesses to a large chunk of fast memory is unASICable. That data vector could be derived by the same means as an one time pad, and loaded and locked into memory after boot. If you make it large enough it won't profit from embedded RAM bandwidth/speedup. The only way to speed up would be clustering, which doesn't offer economies of scale.