Date: Tue, 20 Sep 2022 21:28:12 +0200 From: Solar Designer <solar@...nwall.com> To: yescrypt@...ts.openwall.com Subject: Re: ROM in yespower? Hi, I was hoping this mailing list would be more focused on yescrypt proper (and its intended uses) than on yespower (and PoW), but I don't mind using it for both. On Mon, Sep 19, 2022 at 06:25:52PM +0000, m d wrote: > I am a member of the Dogecoin community and myself and a couple others think it would be valuable to explore possible algorithm alternatives that might save our network energy, as an alternative to moving Proof of Stake. I have figured that an easy fix would be to update scrypt that we use, to a compatible version that is tmto resistant. It appears that this was your goal as well in yescrypt and yespower which is encouraging. yespower would discourage ASICs and GPUs. It is not obvious to me how using a CPU PoW affects a network's energy consumption. Do you know of such studies? It could be possible to tweak (modify) yespower such that it'd bump into memory latency rather than computation, which would reduce a typical computer's power consumption while running it. However, under-using a computer like that reduces yespower's "ASIC resistance". > My question is, is there a reason for not including a ROM setting in yespower? I see that in yescrypt it was included to prevent botnets, which I would think that the largest botnet problem is with cryptocurrencies. I assume the lack of ROM was to reduce the potential "knobs" that could be set wrong. Since botnet resistance is a requirement for large, CPU only, cryptocurrencies; would adding a ROM "knob" in yespower be possible? What ROM size would you use? With yescrypt, I recommend 100+ GB in RAM. If you do that with yespower and your wallet software is such that it needs to verify PoW (like bitcoin-qt derivatives do), then each machine running the wallet would need that much RAM to have decent performance. So you'd end up with a much smaller ROM, like 1 GB maybe, which wouldn't be enough against botnets. OTOH, if your users only use lightweight wallets anyway (trusting remote nodes on that sub-network), then you can probably use large ROMs. Other reasons to remove the ROM were simplicity and desire to better differentiate yescrypt's usage for password hashing from yespower's for PoW. So that potential ASICs for the two would be distinct. It is indeed possible to re-add ROM to yespower. > Just setting N very high I don't think would be ideal Right, it wouldn't be ideal because it'd increase verification time. While I'm aware of some tricks (Bitcoin-derived tree changes) to allow for higher N than simply swapping in yespower would accommodate, those have their limitations. Indeed, N would still not be high enough to prevent botnets. Besides, if it were that high, we'd also hurt usability of full-node wallets (just like a large ROM would). > because then that would negate the fast L2 benefit of a CPU, unless I am mistaken. No, yespower targets L2 cache with its S-boxes, the size of which is set separately from N. (It is currently hard-coded at 96 KiB per thread.) A reasonable N*r is such that e.g. 16 MiB is used per thread, which is way above typical L2 cache sizes anyway. BTW, Ethash's and later ProgPoW's DAG is conceptually similar to yescrypt's ROM. Differences include their targeting of GPUs rather than CPUs, and their lack of a sequential-memory hard component (the kind of usage of RAM pioneered in scrypt). RandomX targets CPUs and has all of those things, so you could consider it. I hope this helps. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.