public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] ASIC-proof mining
Date: Fri, 04 Jul 2014 11:27:51 +0100	[thread overview]
Message-ID: <10566815.3CllqoMfON@momentum> (raw)

Hello,

I had a thought after reading Mike Hearn's blog about it being impossible to 
have an ASIC-proof proof of work algorithm.

Perhaps I'm being dim, but I thought I'd mention my thought anyway.

It strikes me that he's right that it's impossible for any algorithm to exist 
that can't be implemented in an ASIC.  However, that's only because it's 
trying to pick an algorithm that is CPU bound.  You could protect against ASCI 
mining (or rather, make it irrelevant that it was being used) by making the 
algorithm IO-bound rather than CPU-bound.

For example, what if the proof-of-work hash for a block were no longer just 
"hash of block", which contains the hash of the parent block, but instead were 
hash of 

   [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]

[ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing.  By prefixing and 
suffixing the new block, you have to feed every byte of the blockchain through 
the hashing engine (the prefix prevents you caching the intermediate result).  
Whatever bus you're using to feed your high speed hashing engine, it will 
always be faster than the bus -- hence you're now IO-bound, not CPU-bound, and 
any hashing engine will, effectively, be the same.

I'm making the assumption that SHA-256 is not cacheable from the middle 
outwards, so the whole block-chain _has_ to be transferred for every hash.

Apologies in advance if this is a stupid idea.



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com




             reply	other threads:[~2014-07-04 10:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04 10:27 Andy Parkins [this message]
2014-07-04 10:53 ` [Bitcoin-development] ASIC-proof mining Alan Reiner
2014-07-04 11:08   ` Eugen Leitl
2014-07-04 11:15   ` Andy Parkins
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=10566815.3CllqoMfON@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