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
| ||
|
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
Powered by blists - more mailing lists