Bitcoin Core
PoW Scrypt Token based on Bitcoin
Proof of Work Algorithm
​
A proof-of-work (POW) system (or protocol, or function) is an economic measure to deter denial of service attacks and other service abuses such as spam on a network by requiring some work from the service requester, usually meaning processing time by a computer. The concept was invented by Cynthia Dwork and Moni Naor as presented in a 1993 journal article.[1] The term "Proof of Work" or POW was first coined and formalized in a 1999 paper by Markus Jakobsson and Ari Juels.[2] An early example of the proof-of-work system used to give value to a currency is the Shell Money of the Solomon Islands.
A key feature of these schemes is their asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. This idea is also known as a CPU cost function, client puzzle, computational puzzle or CPU pricing function. It is distinct from a CAPTCHA, which is intended for a human to solve quickly, rather than a computer. Proof of space (PoS) proposals apply the same principle by proving a dedicated amount of memory or disk space instead of CPU time. Proof of bandwidthapproaches have been discussed in the context of cryptocurrency. Proof of ownership aims at proving that specific data are held by the prover.
​
Source: https://en.wikipedia.org/wiki/Proof-of-work_system
​
Scrypt
​
The large memory requirements of scrypt come from a large vector of pseudorandom bit strings that are generated as part of the algorithm. Once the vector is generated, the elements of it are accessed in a pseudo-random order and combined to produce the derived key. A straightforward implementation would need to keep the entire vector in RAM so that it can be accessed as needed.
Because the elements of the vector are generated algorithmically, each element could be generated on the fly as needed, only storing one element in memory at a time and therefore cutting the memory requirements significantly. However, the generation of each element is intended to be computationally expensive, and the elements are expected to be accessed many times throughout the execution of the function. Thus there is a significant trade-off in speed in order to get rid of the large memory requirements.
This sort of time–memory trade-off often exists in computer algorithms: speed can be increased at the cost of using more memory, or memory requirements decreased at the cost of performing more operations and taking longer. The idea behind scrypt is to deliberately make this trade-off costly in either direction. Thus an attacker could use an implementation that doesn't require many resources (and can therefore be massively parallelized with limited expense) but runs very slowly, or use an implementation that runs more quickly but has very large memory requirements and is therefore more expensive to parallelize.
​
Source: https://en.wikipedia.org/wiki/Scrypt
​
Algorithm example:
Function scrypt
Inputs:
Passphrase: Bytes string of characters to be hashed
Salt: Bytes random salt
CostFactor (N): Integer CPU/memory cost parameter
BlockSizeFactor (r): Integer blocksize parameter (8 is commonly used)
ParallelizationFactor (p): Integer Parallelization parameter. (1..232-1 * hLen/MFlen)
DesiredKeyLen: Integer Desired key length in bytes
Output:
DerivedKey: Bytes array of bytes, DesiredKeyLen long
Step 1. Generate expensive salt
blockSize ← 128*BlockSizeFactor //Length (in bytes) of the SMix mixing function output (e.g. 128*8 = 1024 bytes)
Use PBKDF2 to generate initial 128*BlockSizeFactor*p bytes of data (e.g. 128*8*3 = 3072 bytes)
Treat the result as an array of p elements, each entry being blocksize bytes (e.g. 3 elements, each 1024 bytes)
[B0...Bp−1] ← PBKDF2HMAC-SHA256(Passphrase, Salt, 1, blockSize*ParallelizationFactor)
Mix each block in B 2CostFactor times using ROMix function (each block can be mixed in parallel)
for i ← 0 to p-1 do
Bi ← ROMix(Bi, 2CostFactor)
All the elements of B is our new "expensive" salt
expensiveSalt ← B0∥B1∥B2∥ ... ∥Bp-1 //where ∥ is concatenation
Step 2. Use PBKDF2 to generate the desired number of bytes, but using the expensive salt we just generated
return PBKDF2HMAC-SHA256(Passphrase, expensiveSalt, 1, DesiredKeyLen);
Key Derivation
​
A password-based key derivation function (password-based KDF) is generally designed to be computationally intensive, so that it takes a relatively long time to compute (say on the order of several hundred milliseconds). Legitimate users only need to perform the function once per operation (e.g., authentication), and so the time required is negligible. However, a brute-force attack would likely need to perform the operation billions of times, at which point the time requirements become significant and, ideally, prohibitive.
Previous password-based KDFs (such as the popular PBKDF2 from RSA Laboratories) have relatively low resource demands, meaning they do not require elaborate hardware or very much memory to perform. They are therefore easily and cheaply implemented in hardware (for instance on an ASIC or even an FPGA). This allows an attacker with sufficient resources to launch a large-scale parallel attack by building hundreds or even thousands of implementations of the algorithm in hardware and having each search a different subset of the key space. This divides the amount of time needed to complete a brute-force attack by the number of implementations available, very possibly bringing it down to a reasonable time frame.
The scrypt function is designed to hinder such attempts by raising the resource demands of the algorithm. Specifically, the algorithm is designed to use a large amount of memory compared to other password-based KDFs,[4] making the size and the cost of a hardware implementation much more expensive, and therefore limiting the amount of parallelism an attacker can use, for a given amount of financial resources.
​
Source: https://en.wikipedia.org/wiki/Scrypt
​
Adoption:
Adoption will not be a challenge as we now have the core name and title for our Scrypt ERC20 compatible blockchain token. We expect to see adoption from early adopters and the early majority as popularity of the Bitcoin name grows.