public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] ASIC-proof mining
Date: Fri, 04 Jul 2014 12:15:35 +0100	[thread overview]
Message-ID: <2734024.vxftdBi7Ll@momentum> (raw)
In-Reply-To: <53B687BB.9010103@gmail.com>

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




  parent reply	other threads:[~2014-07-04 11:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04 10:27 [Bitcoin-development] ASIC-proof mining Andy Parkins
2014-07-04 10:53 ` Alan Reiner
2014-07-04 11:08   ` Eugen Leitl
2014-07-04 11:15   ` Andy Parkins [this message]
2014-07-04 11:22     ` Alan Reiner
2014-07-04 11:28       ` Andy Parkins
2014-07-04 11:37 ` Gregory Maxwell
2014-07-04 12:01   ` Andy Parkins
2014-07-04 15:20     ` Mike Hearn
2014-07-04 16:50 ` kjj
2014-07-04 18:39   ` Ron Elliott
2014-07-04 19:54     ` Aaron Voisine
2014-07-04 20:21   ` Jorge Timón
2014-07-04 20:38     ` Luke Dashjr
2014-07-04 20:55     ` Randi Joseph
2014-07-05  8:43       ` Mike Hearn
2014-07-07  0:20         ` Randi Joseph
2014-07-07  6:12           ` Odinn Cyberguerrilla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2734024.vxftdBi7Ll@momentum \
    --to=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox