[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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