[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150403142253.GA26881@openwall.com>
Date: Fri, 3 Apr 2015 17:22:53 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Panel: Please require the finalists to help with benchmarks
On Fri, Apr 03, 2015 at 01:34:11PM +0000, Gregory Maxwell wrote:
> If I must. I wasn't going to respond on Bitcoin things-- they're
> largely out of scope, for this list (for reasons I'll explain now
> below).
Thank you for responding. I think at least knowing that those things
are "largely out of scope" is helpful to us.
> Some people, like John Tromp, have been exploring the space of other
> kinds of POW functions that achieve properties like using memory
> hardness while minimizing the harm against other considerations here;
> but this is specialized work and heads off in a very different
> direction than PHC. (I have doubts about how worthwhile those efforts
> are either, but at least they're done with a careful mind to the
> application requirements and tradeoffs by someone who understands
> them).
FWIW, here's an attempt at an asymmetric memory-hard PoW by Bram Cohen,
the inventor of BitTorrent:
http://bramcohen.com/2014/11/24/a-crazy-idea-for-proofs-of-work
He's also been interested in what we're doing here in PHC:
http://bramcohen.com/2014/11/18/a-mode-for-password-hashing
Maybe some hybrid approach would work best for cryptocurrencies that
want to encourage CPU mining: use a memory-hard PHC candidate (or the
like) at fairly low settings (but not to the point of the area cost
being negligible) as a building block in an asymmetric memory-hard PoW,
like what Bram described? For example, a 2 MB symmetric hash expanded
to a 2 GB asymmetric PoW. That way, possible flaws of the asymmetric
memory-hard PoW would be partially mitigated by use of the likely better
understood symmetric memory-hard hash.
Alexander
Powered by blists - more mailing lists