lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 09 Sep 2014 15:45:28 -0400
From: Bill Cox <>
Subject: Re: [PHC] BSTY - yescrypt-based cryptocoin

Hash: SHA1

On 09/09/2014 01:36 PM, Bill Cox wrote:
> On 09/09/2014 07:50 AM, Solar Designer wrote:
>> Hi,
>> A yescrypt-based cryptocoin was launched ~12 hours ago:
>> Before this patch, BSTY mining ran at 1300 hashes/s on i7-4770K. 
>> With the patch, it's the expected 3400 hashes/s (same as my
>> "userom 0 2" benchmark reports for 8 threads).  However, the
>> speed drops to zero whenever the wallet loses connection to
>> network, which happens very often (perhaps overloaded nodes).
> I just started it up on my testing server (yes, my son's MineCraft 
> server).  With your patch it does up to 3,100-ish hashes/second, 
> slightly below what your processor does.  It has mined 1,388 BSTY
> so far.  I'm rich! :-P
> Now... how can I get a free graphics card out of this again?  :-)

I did a quick comparison of TwoCats and Yescrypt when doing 2MiB
hashes.  Yescrypt maxes out my machine at about 3,100 hashes per
second using 8 threads, which gives the best performance.  TwoCats
maxes out at about 3,800 similar sized hashes on 3 threads with 2
multiplications per inner loop, which gives the best performance.
However, Yescrypt is doing something like 2.3 memory read/writes per
location vs TwoCat's 2.  The difference is basically in the noise.

I think Yescrypt has a better chance of being a winning entry than
TwoCats, and it is designed by Solar Designer.  I can't blame these
guys for picking Yescrypt for proof of work.  It's jumping the gun,
but there's a significant first-mover advantage in this BitCoin-fork

I wonder about the choice not to bust into external DRAM.  This size
hash could fit between 4 and 8 2MiB cache RAMs on a high-end ASIC
(same process as my CPU).  Had they used 32MiB or more, the ASIC might
need high-speed external DRAM interfaces, and these things are tricky
to get right, significantly complicating an ASIC effort.

Still, there's probably no more than about a 10X speed improvement for
a very high-end ASIC vs my CPU (4 cores running 25% faster).  That's
really fantastic ASIC defense.  I wouldn't expect to see such a
high-end ASIC for this application for a long time.  It is possible
that this system will succeed at distributing the hashing load (and
mining profits) evenly among users, which would be very cool.  It
seems a lot more fair to let anyone running a client be on essentially
the same level as everyone else.

Version: GnuPG v1


Powered by blists - more mailing lists