Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <andyparkins@gmail.com>) id 1X31T0-0002UH-9O
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Jul 2014 11:15:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.179 as permitted sender)
	client-ip=74.125.82.179; envelope-from=andyparkins@gmail.com;
	helo=mail-we0-f179.google.com; 
Received: from mail-we0-f179.google.com ([74.125.82.179])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1X31Sy-0003m9-I0
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Jul 2014 11:15:46 +0000
Received: by mail-we0-f179.google.com with SMTP id w62so1540231wes.10
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 04 Jul 2014 04:15:38 -0700 (PDT)
X-Received: by 10.194.61.47 with SMTP id m15mr11779350wjr.63.1404472538351;
	Fri, 04 Jul 2014 04:15:38 -0700 (PDT)
Received: from momentum.localnet ([91.84.15.31])
	by mx.google.com with ESMTPSA id
	lo18sm78145750wic.1.2014.07.04.04.15.36 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 04 Jul 2014 04:15:37 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Fri, 04 Jul 2014 12:15:35 +0100
Message-ID: <2734024.vxftdBi7Ll@momentum>
User-Agent: KMail/4.12.4 (Linux/3.10-2-amd64; KDE/4.13.1; x86_64; ; )
In-Reply-To: <53B687BB.9010103@gmail.com>
References: <10566815.3CllqoMfON@momentum> <53B687BB.9010103@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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
	(andyparkins[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: 1X31Sy-0003m9-I0
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:15:46 -0000

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.

> 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.

But we want that read.  Remember the actual hash rate isn't important, what 
matters is how hard it is to reproduce.  If we make it 1000x harder to do one 
hash for everybody, we're still just as secure.  The difficulty adjustment 
algorithm ensures blocks come at 10 minutes, regardless of hash rate.  So we 
can make it harder by picking a harder algorithm -- SCRYPT or BLOWFISH, or 
just by upping the size of the data that needs hashing.  The advantage of 
upping the size of the input is that, unlike an algorithm change, you can't 
build a better ASIC to reduce the size.


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com