Date: Tue, 09 Sep 2014 15:45:28 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] BSTY - yescrypt-based cryptocoin

-----BEGIN PGP SIGNED MESSAGE-----
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:
> 
>> https://bitcointalk.org/index.php?topic=775289.0 
>> https://github.com/GlobalBoost/GlobalBoost-Y 
>> https://bst.globalboo.st/y/product.php?id=22
> 
>> 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
space.

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.

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUD1jVAAoJEAcQZQdOpZUZrxAP/Ahu+k5MWCgyKRMSnMGRLySZ
e3OLTgIoocb2mvAi26Tv3Eb0ofaXqcXNvs3mJUupiMhXySYw0XZNsBObMJQOxj2I
bLJFGbCaOHPngKPyTuk85mmJFMcBMan+hRc5nJkioB1VB67PNT9UFlkIkd9TQkKr
3uX8xriZ3JYr76zZx8PSd9lNwgpjPJc3hrZktG7wmUBTlJY9G+2hu9UR964cJ/P2
JFkaxIL2yAckkOu0YqKPvote+q91nVB+TR/KPi4a8rbt5bZG4gu8HX7uV8KG3qqh
D3j6BsUCmbrnBLpkFLTX6ddoMubb2tzQsAkjgwU59uL+5I3X7BeRB/wHQ0w+zrTa
NVmZglRY3AOT5IPlVY8ndti+/JREoAwwB/zXU6p4UiuINrG7kq6od1U7/dyUUQyo
MyejKf2wIBqoX/Z8yDCtxVzhHKCx73/5TKb4Vh4Bkudhg6yo7xd2v+WDfrsBGshG
4RutQzTOQjCylTdun0fE4WPsX/32/JkSR35SK8WsVcn3YzdldjHikRkMDCP+ZwDP
ntwZp1NPIhIO3RKeiH6AsdVRhdJLAIgDJD/8Nb88nzzTv1A1LRrLGVQCtIxFTzf6
gyT5af7kftDeLg5oRI2oYVc8CXHz5bty1XhERDw+kOGKEhUMuE+q+Deo0C3/0jDN
B58tNxHXr1sXOVBEQydE
=ODxS
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists