public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@monetize.io>
To: kjj <bitcoin-devel@jerviss.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ASIC-proof mining
Date: Fri, 4 Jul 2014 22:21:42 +0200	[thread overview]
Message-ID: <CAC1+kJOSAoz_BBaFnv4u-Dng7Y4h2tqOHSFRfuKvY87eBR71Gw@mail.gmail.com> (raw)
In-Reply-To: <53B6DB38.7010709@jerviss.org>

On 7/4/14, kjj <bitcoin-devel@jerviss.org> wrote:
> I suspect that there exist no algorithms which cannot be done better in
> an application-specific device than in a general purpose computer.  And
> if there is such a thing, then it must necessarily perform best on one
> specific platform, making that platform the de facto application
> specific device.
>
> I'm not sure how one would go about proving or disproving that, but it
> seems very likely to be true.

I assumed this was obvious and self-evident for anyone who knows what
a Turing machine is, but judging from the number of smart people
wasting their time on the pursue of the "anti-ASIC" myth (also known
as pow wankery) it seems I was wrong.
Anything you can do with software you can do with hardware and
viceversa (you can even do it with ropes and fire in Minecraft!!)
Does this really need any proof?
I think it's the hard-pow cultists who have to provide a counterexample.

Very often you just need to query-replace "ASIC" with "specialized
hardware" to prove that what they're saying makes no sense.

> Keeping the algorithm simple, and ASIC-easy, has one other advantage.
> Just about anyone can sit down and design an ASIC for SHA, for example,
> leading to diversity in the marketplace.  A harder algorithm can still
> be made into an ASIC (or more generally into an ASD), but will require
> more skilled designers, more expensive fabrication, etc.  This actually
> concentrates the ASIC advantage into the hands of fewer people, which
> again, is contrary to the stated goals.

Yep, I think this is the strongest argument against "hard-pow".
But unfortunately you even find people that want "anti-ASIC without
being anti-GPU", which is funny because GPU just has Nvidia and AMD
and because unlike "anti-ASIC", anti-GPU is actually possible (despite
Litecoin's Scrypt having miserably failed on both accounts).

Interestingly enough, Greg Maxwell told me that the energetc advantage
of memory-hard pow ASICs is even greater than the advantage for SHA
ASICs.

Anyway, I'm working on a branch to encapsulate the proof of work that
should serve people to more easily experiment with alternate proofs on
top of bitcoind's code. I plan to use it for private chains ("proof of
signature" or "proof of script" if you prefer), and although it's not
ready yet, some people may be interested or may want to give some
feedback:

https://github.com/jtimon/bitcoin/tree/proof

I don't know if it will make it into master, but by specializing
ProofOfWork with TestnetProofOfWork we could remove
Params().AllowMinDifficultyBlocks() and its checks.

-- 
Jorge Timón



  parent reply	other threads:[~2014-07-04 20:21 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
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 [this message]
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=CAC1+kJOSAoz_BBaFnv4u-Dng7Y4h2tqOHSFRfuKvY87eBR71Gw@mail.gmail.com \
    --to=jtimon@monetize.io \
    --cc=bitcoin-devel@jerviss.org \
    --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