| http://wiki.ethereum.org/index.php/Dagger#Algorithm_specific...: You sound knowledgeable, so perhaps you could clean up their algorithm for me? There are a number of problems with their description that make it hard for me to evaluate. Having tried designing a memory-hard algorithm, I'd like to see what their key insight was, but there are a number of problems with their article. They use confusing operators, the wrong terms, and seemingly random constants. How did they come up with the numbers 2, 3, 11, 2^21, and 2^22, for example? Is D the hash function or the underlying data? Or is 'data' the underlying data? Does + mean addition or string concatenation? What about "++"? They never even use "||", which they defined as string concatenation... Where does the nonce N come in? Is that actually supposed to be 'n'? How do they justify that the optimal algorithm is the naive one? There is essentially no proof of this claim in the article. In short, I'm very suspicious of their "memory-hard" algorithm. It took a fairly dense, multi-page whitepaper to explain Scrypt, and yet their 'superior' version is just a couple of sloppy lines of pseudocode with no justification. Here is what they wrote, for reference: Let D be the underlying data (eg. in Bitcoin's case the block header), N be the nonce and || be the string concatenation operator (ie. 'foo' || 'bar' == 'foobar') . The entire code for the algorithm is as follows: 0: D(data,xn,0) = sha3(data) 1: D(data,xn,n) = 2: with v = sha3(data + xn + n) 3: L = 2 if n < 2^21 else 11 if n < 2^22 else 3 4: a[k] = floor(v/n^k) mod n for 0 <= k < 2 5: a[k] = floor(v/n^k) mod 2^22 for 2 <= k < L 6: sha3(v ++ D(data,xn,a[0]) ++ D(data,xn,a[1]) ++ ... ++ D(data,xn,a[L-1])) |
It has the following features:
1) proofs take the form of a length 42 cycle in the Cuckoo graph, so that verification only requires computing 42 hashes.
2) the graph size (number of nodes) can scale from 1x2^10 to 7x2^29 with 4 bytes needed per node, so memory use scales from 4KB to 14GB. Use of 4GB+ should make it somewhat resistent to botnets.
3) running time is roughly linear in memory, at under 1min/GB for the current implementation on high end x86.
4) no time-memory trade-off (TMTO) is known, and memory access patterns are the worst possible, making the algorithm constrained by memory latency.
5) it has a natural notion of difficulty, namely the number of edges in the graph; above about 60% of size, a 42-cycle is almost guaranteed, but below 50% the probability starts to fall sharply.
6) the choice of cycle length allows a tradoff between benefit (algorithmic hardness) and cost (proof size), similar to the choice of the number of rounds in a cryptographic hash or encryption function.