Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1X31ZY-0004Uq-Cu
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Jul 2014 11:22:32 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.51 as permitted sender)
	client-ip=74.125.82.51; envelope-from=etotheipi@gmail.com;
	helo=mail-wg0-f51.google.com; 
Received: from mail-wg0-f51.google.com ([74.125.82.51])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1X31ZU-0000Jf-K8
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Jul 2014 11:22:30 +0000
Received: by mail-wg0-f51.google.com with SMTP id x12so1504808wgg.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 04 Jul 2014 04:22:22 -0700 (PDT)
X-Received: by 10.180.88.194 with SMTP id bi2mr16931022wib.71.1404472941389;
	Fri, 04 Jul 2014 04:22:21 -0700 (PDT)
Received: from [172.11.13.74] ([31.216.236.194])
	by mx.google.com with ESMTPSA id
	ek3sm68400825wjd.17.2014.07.04.04.22.20 for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 04 Jul 2014 04:22:20 -0700 (PDT)
Message-ID: <53B68E6B.6090602@gmail.com>
Date: Fri, 04 Jul 2014 07:22:19 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Andy Parkins <andyparkins@gmail.com>, 
	bitcoin-development@lists.sourceforge.net
References: <10566815.3CllqoMfON@momentum> <53B687BB.9010103@gmail.com>
	<2734024.vxftdBi7Ll@momentum>
In-Reply-To: <2734024.vxftdBi7Ll@momentum>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.6 (-)
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
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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: 1X31ZU-0000Jf-K8
Subject: Re: [Bitcoin-development] ASIC-proof mining
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2014 11:22:32 -0000


On 07/04/2014 07:15 AM, Andy Parkins wrote:
> On Friday 04 July 2014 06:53:47 Alan Reiner wrote:
>
>> ROMix works by taking N sequential hashes and storing the results into a
>> single N*32 byte lookup table.   So if N is 1,000,000, you are going to
>> compute 1,000,000 and store the results into 32,000,000 sequential bytes
>> of RAM.  Then you are going to do 1,000,000 lookup operations on that
>> table, using the hash of the previous lookup result, to determine the
>> location of next lookup (within that 32,000,000 bytes).  Assuming a
>> strong hash function, this means its impossible to know in advance what
>> needs to be available in RAM to lookup, and it's easiest if you simply
>> hold all 32,000,000 bytes in RAM.
> My idea wasn't to make hashing memory hungry; it was to make it IO-hungry.  It 
> wouldn't be too hard to make an ASIC with 32MB of RAM.  Especially if it 
> gained you a 1000x advantage over the other miners.  It seems that sort of 
> solution is exactly the one that Mike Hearn was warning against in his blog.

I think you misundersood....  using ROMix-like algorithm, each hash
requires a different 32 MB of the blockchain.  Uniformly distributed
throughout the blockchain, and no way to predict which 32 MB until you
have actually executed it.   If the difficulty is high enough, your
miner is likely to end up going through the entire X GB blockchain while
searching for a good hash, but other nodes will only need to do 32 MB
worth of disk accesses to verify your answer (and it will be unknown
which 32 MB until they do the 1,000,000 hash+lookup operations on their
X GB blockchain).

I think that strikes a good compromise of needing access to 100% of the
blockchain, without requiring reading 20 GB to verify a block.

(Replace N=1,000,000, 32 MB and 20 GB with the appropriately calibrated
numbers in the future)