yespower - proof-of-work (PoW) scheme
yespower is a proof-of-work (PoW) focused fork of yescrypt, which in turn builds upon scrypt.
While yescrypt is a password-based key derivation function (KDF) and password hashing scheme,
and thus is meant for processing passwords,
yespower is meant for processing trial inputs such as block headers (including nonces) in PoW-based blockchains.
Download
(current release notes,
original release notes):
This and (eventually) older versions of yespower will also be
available from the Openwall file archive.
The source code of yespower can be browsed on
GitHub.
Follow this link for information on verifying the signatures.
We can help you integrate yespower into your software or online services.
Please check out our services.
yespower consortium
Cryptocurrency projects that use yespower are expected to join the informal yespower consortium,
which involves supporting the yespower project financially and having more of a say on its future direction.
Without endorsing any of these projects in any way, we currently list the "consortium members" here
so that the different cryptocurrency projects and their users know which projects are significantly
supporting yespower upstream development (those listed here) and which don't (the rest).
Currently, there's just one:
Please contact us about joining the consortium.
Why or why not yespower?
Different proof-of-work schemes in existence vary in many aspects,
including in friendliness to different types of hardware. There's
demand for all sorts of hardware (un)friendliness in those - for
different use cases and by different communities.
yespower in particular is designed to be CPU-friendly, GPU-unfriendly,
and FPGA/ASIC-neutral. In other words, it's meant to be relatively
efficient to compute on current CPUs and relatively inefficient on
current GPUs. Unfortunately, being GPU-unfriendly also means that
eventual FPGA and ASIC implementations will only compete with CPUs, and
at least ASICs will win over the CPUs (FPGAs might not because of this
market's peculiarities - large FPGAs are even more "over-priced" than
large CPUs are), albeit by far not to the extent they did e.g. for
Bitcoin and Litecoin.
There's a lot of talk about "ASIC resistance". What is (or should be)
meant by that is limiting the advantage of specialized ASICs. While
limiting the advantage at KDF to e.g. 10x and at password hashing to
e.g. 100x (talking orders of magnitude here, in whatever terms) may be
considered "ASIC resistant" (as compared to e.g. 100,000x we'd have
without trying), similar improvement factors are practically not "ASIC
resistant" for cryptocurrency mining where they can make all the
difference between CPU mining being profitable and not. There might
also exist in-between PoW use cases where moderate ASIC advantage is OK,
such as with non-cryptocurrency and/or private/permissioned blockchains.
Thus, current yespower may be considered either a short-term choice
(valid until one of its uses provides sufficient perceived incentive to
likely result in specialized ASICs) or a deliberate choice of a pro-CPU,
anti-GPU, moderately-pro-ASIC PoW scheme. It is also possible to
respond to known improvements in future GPUs/implementations and/or to
ASICs with new versions of yespower that users would need to switch to.
yespower versions
yespower includes optimized and specialized re-implementation of the
obsolete yescrypt 0.5 (based off its first submission to
Password Hashing Competition back in 2014)
now re-released as yespower 0.5, and brand new proof-of-work specific variation known as yespower 1.0.
yespower 0.5 is intended as a compatible upgrade for cryptocurrencies
that already use yescrypt 0.5 (providing a few percent speedup), and
yespower 1.0 may be used as a further upgrade or a new choice of PoW by
those and other cryptocurrencies and other projects.
There are many significant differences between yespower 0.5 and 1.0
under the hood, but the main user visible difference is yespower 1.0
greatly improving on GPU-unfriendliness in light of improvements seen in
modern GPUs (up to and including NVIDIA Volta) and GPU implementations
of yescrypt 0.5. This is achieved mostly through greater use of CPUs'
L2 cache.
The version of algorithm to use is requested through parameters,
allowing for both algorithms to co-exist in client and miner
implementations (such as in preparation for a cryptocurrency hard-fork
and/or supporting multiple cryptocurrencies in one program).
117880
