[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220920192812.GA31524@openwall.com>
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.
