{"id":20135967,"url":"https://github.com/openwall/yespower","last_synced_at":"2025-04-09T17:33:36.917Z","repository":{"id":136729097,"uuid":"328225316","full_name":"openwall/yespower","owner":"openwall","description":"Proof-of-work scheme building upon yescrypt and scrypt","archived":false,"fork":false,"pushed_at":"2025-03-09T02:47:25.000Z","size":66,"stargazers_count":31,"open_issues_count":1,"forks_count":22,"subscribers_count":6,"default_branch":"main","last_synced_at":"2025-03-23T19:39:15.048Z","etag":null,"topics":["blockchain","cryptocurrency","pow","proof-of-work","scrypt","yescrypt"],"latest_commit_sha":null,"homepage":"https://www.openwall.com/yespower/","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/openwall.png","metadata":{"files":{"readme":"README","changelog":"CHANGES","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-01-09T18:57:01.000Z","updated_at":"2025-03-19T01:22:57.000Z","dependencies_parsed_at":"2023-08-29T21:31:20.582Z","dependency_job_id":null,"html_url":"https://github.com/openwall/yespower","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openwall%2Fyespower","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openwall%2Fyespower/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openwall%2Fyespower/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openwall%2Fyespower/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/openwall","download_url":"https://codeload.github.com/openwall/yespower/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248077690,"owners_count":21044008,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["blockchain","cryptocurrency","pow","proof-of-work","scrypt","yescrypt"],"created_at":"2024-11-13T21:17:11.001Z","updated_at":"2025-04-09T17:33:36.778Z","avatar_url":"https://github.com/openwall.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"\tWhat is yespower?\n\nyespower is a proof-of-work (PoW) focused fork of yescrypt.  While\nyescrypt is a password-based key derivation function (KDF) and password\nhashing scheme, and thus is meant for processing passwords, yespower is\nmeant for processing trial inputs such as block headers (including\nnonces) in PoW-based blockchains.\n\nOn its own, yespower isn't a complete proof-of-work system.  Rather, in\nthe blockchain use case, yespower's return value is meant to be checked\nfor being numerically no greater than the blockchain's current target\n(which is related to mining difficulty) or else the proof attempt\n(yespower invocation) is to be repeated (with a different nonce) until\nthe condition is finally met (allowing a new block to be mined).  This\nprocess isn't specific to yespower and isn't part of yespower itself\n(rather, it is similar in many PoW-based blockchains and is to be\ndefined and implemented externally to yespower) and thus isn't described\nin here any further.\n\n\n\tWhy or why not yespower?\n\nDifferent proof-of-work schemes in existence vary in many aspects,\nincluding in friendliness to different types of hardware.  There's\ndemand for all sorts of hardware (un)friendliness in those - for\ndifferent use cases and by different communities.\n\nyespower in particular is designed to be CPU-friendly, GPU-unfriendly,\nand FPGA/ASIC-neutral.  In other words, it's meant to be relatively\nefficient to compute on current CPUs and relatively inefficient on\ncurrent GPUs.  Unfortunately, being GPU-unfriendly also means that\neventual FPGA and ASIC implementations will only compete with CPUs, and\nat least ASICs will win over the CPUs (FPGAs might not because of this\nmarket's peculiarities - large FPGAs are even more \"over-priced\" than\nlarge CPUs are), albeit by far not to the extent they did e.g. for\nBitcoin and Litecoin.\n\nThere's a lot of talk about \"ASIC resistance\".  What is (or should be)\nmeant by that is limiting the advantage of specialized ASICs.  While\nlimiting the advantage at KDF to e.g. 10x and at password hashing to\ne.g. 100x (talking orders of magnitude here, in whatever terms) may be\nconsidered \"ASIC resistant\" (as compared to e.g. 100,000x we'd have\nwithout trying), similar improvement factors are practically not \"ASIC\nresistant\" for cryptocurrency mining where they can make all the\ndifference between CPU mining being profitable and not.  There might\nalso exist in-between PoW use cases where moderate ASIC advantage is OK,\nsuch as with non-cryptocurrency and/or private/permissioned blockchains.\n\nThus, current yespower may be considered either a short-term choice\n(valid until one of its uses provides sufficient perceived incentive to\nlikely result in specialized ASICs) or a deliberate choice of a pro-CPU,\nanti-GPU, moderately-pro-ASIC PoW scheme.  It is also possible to\nrespond to known improvements in future GPUs/implementations and/or to\nASICs with new versions of yespower that users would need to switch to.\n\n\n\tyespower versions.\n\nyespower includes optimized and specialized re-implementation of the\nobsolete yescrypt 0.5 (based off its first submission to Password\nHashing Competition back in 2014) now re-released as yespower 0.5, and\nbrand new proof-of-work specific variation known as yespower 1.0.\n\nyespower 0.5 is intended as a compatible upgrade for cryptocurrencies\nthat already use yescrypt 0.5 (providing a few percent speedup), and\nyespower 1.0 may be used as a further upgrade or a new choice of PoW by\nthose and other cryptocurrencies and other projects.\n\nThere are many significant differences between yespower 0.5 and 1.0\nunder the hood, but the main user visible difference is yespower 1.0\ngreatly improving on GPU-unfriendliness in light of improvements seen in\nmodern GPUs (up to and including NVIDIA Volta) and GPU implementations\nof yescrypt 0.5.  This is achieved mostly through greater use of CPUs'\nL2 cache.\n\nThe version of algorithm to use is requested through parameters,\nallowing for both algorithms to co-exist in client and miner\nimplementations (such as in preparation for a cryptocurrency hard-fork\nand/or supporting multiple cryptocurrencies in one program).\n\n\n\tParameter selection.\n\nFor new uses of yespower, set the requested version to the highest\nsupported, and set N*r to the highest you can reasonably afford in terms\nof proof verification time (which might in turn be determined by desired\nshare rate per mining pool server), using one of the following options:\n\n1 MiB: N = 1024, r = 8\n2 MiB: N = 2048, r = 8\n4 MiB: N = 1024, r = 32\n8 MiB: N = 2048, r = 32\n16 MiB: N = 4096, r = 32\n\nand so on for higher N keeping r=32.\n\nYou may also set the personalization string to your liking, but that is\nnot required (you can set its pointer to NULL and its length to 0).  Its\nsupport is provided mostly for compatibility with existing modifications\nof yescrypt 0.5.\n\n\n\tPerformance.\n\nPlease refer to PERFORMANCE for some benchmarks and performance tuning.\n\n\n\tHow to test yespower for proper operation.\n\nOn a Unix-like system, invoke \"make check\".  This will build and run a\nprogram called \"tests\", and check its output against the supplied file\nTESTS-OK.  If everything matches, the final line of output should be the\nword \"PASSED\".\n\nWe do most of our testing on Linux systems with gcc.  The supplied\nMakefile assumes that you use gcc.\n\n\n\tAlternate code versions and make targets.\n\nTwo implementations of yespower are included: reference and optimized.\nBy default, the optimized implementation is built.  Internally, the\noptimized implementation uses conditional compilation to choose between\nusage of various SIMD instruction sets where supported and scalar code.\n\nThe reference implementation is unoptimized and is very slow, but it has\nsimpler and shorter source code.  Its purpose is to provide a simple\nhuman- and machine-readable specification that implementations intended\nfor actual use should be tested against.  It is deliberately mostly not\noptimized, and it is not meant to be used in production.\n\nSimilarly to \"make check\", there's \"make check-ref\" to build and test\nthe reference implementation.  There's also \"make ref\" to build the\nreference implementation and have the \"benchmark\" program use it.\n\n\"make clean\" may need to be run between making different builds.\n\n\n\tHow to integrate yespower in a program.\n\nAlthough yespower.h provides several functions, chances are that you\nwill only need to use yespower_tls().  Please see the comment on this\nfunction in yespower.h and its example usage in tests.c and benchmark.c,\nincluding parameter sets requesting yescrypt 0.5 as used by certain\nexisting cryptocurrencies.\n\nTo integrate yespower in an altcoin based on Bitcoin Core, you might\ninvoke yespower_tls() from either a maybe-new (depending on where you\nfork from) CBlockHeader::GetPoWHash() (and invoke that where PoW is\nneeded like e.g. Litecoin does for scrypt) or CBlockHeader::GetHash()\n(easier, but inefficient and you'll be stuck with that inefficiency).\n\nYou'll also want to implement caching of the computed PoW hashes like\ne.g. YACoin does for scrypt.  Caching is especially important if you\ninvoke yespower from CBlockHeader::GetHash().  However, even if you use\nor introduce CBlockHeader::GetPoWHash() caching may still be desirable\nas the PoW hash is commonly requested 4 times per block fetched during a\nnode's initial blockchain sync (once during prefetch of block headers,\nand 3 times more during validation of a fully fetched block).  On the\nother hand, you'll likely want to bypass the cache when PoW is computed\nby the node's built-in miner.\n\nFurther detail on this (generating new genesis blocks, etc.) is even\nfarther from being yespower-specific and thus is not provided here.\nJust like (and even more so than) yespower itself, the above guidance is\nprovided as-is and without guarantee of being correct and safe to\nfollow.  You're supposed to know what you're doing.\n\n\n\tCredits.\n\nscrypt has been designed by Colin Percival.  yescrypt and yespower have\nbeen designed by Solar Designer building upon scrypt.\n\nThe following other people and projects have also indirectly helped make\nyespower what it is:\n\n - Bill Cox\n - Rich Felker\n - Anthony Ferrara\n - Christian Forler\n - Taylor Hornby\n - Dmitry Khovratovich\n - Samuel Neves\n - Marcos Simplicio\n - Ken T Takusagawa\n - Jakob Wenzel\n - Christian Winnerlein\n\n - DARPA Cyber Fast Track\n - Password Hashing Competition\n\n\n\tContact info.\n\nFirst, please check the yespower homepage for new versions, etc.:\n\n    https://www.openwall.com/yespower/\n\nIf you have anything valuable to add or a non-trivial question to ask,\nyou may contact the maintainer of yespower at:\n\n    Solar Designer \u003csolar at openwall.com\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenwall%2Fyespower","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenwall%2Fyespower","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenwall%2Fyespower/lists"}