phc-discussions - Re: [PHC] BSTY - yescrypt-based cryptocoin

lists.openwall.net		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]

Message-ID: <20140912151245.GA20606@openwall.com>
Date: Fri, 12 Sep 2014 19:12:45 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] BSTY - yescrypt-based cryptocoin

On Fri, Sep 12, 2014 at 10:36:21AM -0400, Bill Cox wrote:
> I think I prefer the 2 round vs 6 round for this PoW application.
> Designing fast multipliers is hard, but so is designing 2MiB fast
> SRAMs.  Doubling the SRAM bandwidth and cutting the computation speed
> by 3X seems like a reasonable trade-off to me, especially since you
> also gain speed in block chain verification.

Makes sense to me, especially given that we might actually be talking
bandwidth to external DRAM from that ASIC.  Such external bandwidth is
certainly more limited, since with this approach a high number of
instances could be included in the ASIC (the external DRAM is large),
compensating the multiplication latencies by the number of concurrent
instances.

On the other hand, let's not forget that GPUs are a more immediate
concern than ASICs, although e.g. a 2x speedup on a GPU vs. CPU might be
OK - depending on what properties the coin developers want to achieve.

> I might be tempted to increase to 4MiB though :-)

Sure, and more.  Just not when there's no developer behind this coin who
would have any prior experience with another slow PoW coin.  Like I said,
there's room for improvement in another yescrypt-based coin, e.g. to be
created by the folks who worked on YACoin and have learned from it.

> Here's one problem I have with GlobalBoost-Y.  It sounds like a dream
> come true for botnet operators.  Can you think of anything to defend
> against botnet GlobalBoost-Y mining?

Not for GlobalBoost-Y in particular, but another yescrypt-based coin
could choose to make use of the ROM.  The ROM size could be increasing
over time (e.g., every year, on a pre-specified schedule), and it could
be such that typical botnet nodes would likely be too small for mining -
e.g., target machines with 32 GB RAM now, using 20+ GB for mining and
leaving ~12 GB for normal usage of the same machines.  Then enthusiasts
who want to be mining this new coin would simply upgrade their RAM (it's
like $100 for an extra 16 GB of RAM), whereas botnet nodes' legitimate
owners would have no reason to put more RAM into their machines yet (so
most would not).  The ROM would be initialized in half a minute on miner
or wallet startup.

Unfortunately, predictions are unreliable, and I don't see a good way to
avoid hard-coding the ROM size growth schedule.  (Can a parameter like
this be adjusted dynamically much like the "difficulty" is?)  Besides,
it is possible that the 32 GB limitation of desktop CPUs will stay
around for long enough that most desktop system users will actually need
to put 32 GB into their machines.  (Then the same situation might repeat
at a later time with some other arbitrary limit.)  If so, there would be
no way to make a coin that can be efficiently mined on just some current
desktop machines, rather than on all or on none (requiring more
expensive motherboards and CPUs for mining).

So while this ROM thing can be introduced into yet another altcoin, and
could be its selling point, it's no silver bullet.

Alexander