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; 
Date: Fri, 4 Jul 2014 13:08:34 +0200
From: Eugen Leitl <eugen@leitl.org>
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)
Subject: Re: [Bitcoin-development] ASIC-proof mining
Precedence: list

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.