In brief: the only source I can find (that page) just contains a few sloppy lines of pseudocode. Where is real description and proof of its properties?
http://www.reddit.com/r/ethereum/comments/1vh94e/dagger_upda...
Not just in this link but in another that I cannot find, the devs seem to be leaning towards a bybrid PoW/PoS system like Peercoin.
Edit:
Quote was, "We will switch our PoW from Dagger to a hybrid PoW/PoS system to be developed via a bountied competition conducted by our university partners and open to the general community for participation." from https://bitcointalk.org/index.php?topic=428589.0;all.
I guess that in the limit, the speed-up is less relative to Bitcoin-style mining. Still, as long as modern CPUs are not memory-bound during computation of such hashes, ASIC miners would still win.
They will have the more interesting technical challenge of combining integrated hashing circuits with custom memory interfaces, though ;-)
[1] https://www.usenix.org/system/files/login/articles/105516-Br...
I haven't finished reading everything yet, so I maybe totally incorrect. But I doubt Vitalik didn't consider these issues.
Other the hand, Bitcoin doesn't have to replace the complete currency system to become a useful medium for transactions.
So, a low-level of inflation can still be maintained via fiat currency.
(We obviously need a certain amount of inflation to encourage people to invest vs. hoarding their money.)
Unlike managed currencies that target a constant rate of inflation (2%-3% in the case of USD), Ethereum creates currency at a constant rate forever. But as the size of the monetary base grows relative to the constant rate of issuance, the inflation rate tends to 0%.
Eventually, when the monetary base hits a certain size, the rate of ethers lost to bitrot, hardware failures, carelessness, deaths, etc. comes to equal the rate of issuance, the monetary base stops increasing, and inflation rate hits 0%.
Both a simple (and in hindsight probably obvious) solution to the problem of lost currency over time, and a nice compromise between inflationary and deflationary currency models.
"Miners" would have to buy generic hardware that did generic calculations, which actually would have "intrinsic" value since they wouldn't be busy-work to keep things secure, they'd be executing useful computation for a client.
This is a bit like saying, "I wish the computations in TLS/SSL did something useful besides securing the connection". The security IS useful!
I haven't heard of any others, but I'd be curious to know about them.
My opinion is that we need some better generation currencies that are extremely hard to scale for mining before doing advanced stuff with them.
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]))
Few things got my attention - the data structure
>the general idea is to encode the data type and length in a single byte followed by the actual data
Summary: Ethereum's proof-of-work function(called Dagger) is designed to be memory-hard, but someone pointed out that it should be designed to be sequentially-memory-hard instead. Dagger is not, so you can parallelize the computation.
Will the financial derivative portion mean it is a decentralized Intrade? You would create a contract which will depend on the results of a URL action at a certain point. A trusted neutral observer will give the results of an action at a certain date. Did XX party win an election. The transaction is then decided on that date.
So a third party would take some fixed payment and decide the blockchain event between two parties? Anyway I think it is exciting.
* Under [what], "trasaction".
* In a citation below the video, "crytpocurrency". It is of course important to cite correctly, but perhaps it's nicer without the typo.
* Under [why] a repetition, "years years".
Copy is important. :)
Oh boy! Exciting!
