41–50 of 68 posts
An implementation flaw was discovered a few days ago: https://news.ycombinator.com/item?id=7115725
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.
Honestly, I have yet to see a "meta-coin" that seemed viable. While ideas like creating virtual stocks and property ownership in a block chain are cool they all hinge on actually trusting the person backing those currencies/coins. The meta-programming layer here is nice it gives better transaction control, it does not let us do anything new.
Well a cryptocurrency which actually allowed you to pay for distributed computing, that did useful computations - would be a very interesting thing. "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.
I haven't heard of any others, but I'd be curious to know about them.
Am I the only one that finds the resemblance with SteamOS page disturbing? I thought halfway that there will be controller shown. My opinion is that we need some better generation currencies that are extremely hard to scale for mining before doing advanced stuff with them.
Ethereum is designed to be extremely hard to scale for mining. It does not use Bitcoin mining. Go read about it.
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 4: a[k] = floor(v/n^k) mod n for 0 5: a[k] = floor(v/n^k) mod 2^22 for 2 6: sha3(v ++ D(data,xn,a[0]) ++ D(data,xn,a[1]) ++ ... ++ D(data,xn,a[L-1]))
Apart from scripting, they came up with a new proof-of-work function, which takes exponentially more memory to compute compared to checking. It is probably of independent interest. http://wiki.ethereum.org/index.php/Dagger
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?
Apart from scripting, they came up with a new proof-of-work function, which takes exponentially more memory to compute compared to checking. It is probably of independent interest. http://wiki.ethereum.org/index.php/Dagger
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 ;-)
Apart from scripting, they came up with a new proof-of-work function, which takes exponentially more memory to compute compared to checking. It is probably of independent interest. http://wiki.ethereum.org/index.php/Dagger
I'm interested in seeing a real explanation of the Dagger algorithm. 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? https://news.ycombinator.com/item?id=7115825
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.
Apart from scripting, they came up with a new proof-of-work function, which takes exponentially more memory to compute compared to checking. It is probably of independent interest. http://wiki.ethereum.org/index.php/Dagger
Is this a thing that can be mined today? Or is it still paper/brainstorming phase?
No, no a thousand times no... you are building weird machines[1] into the design of the money system. [1] https://www.usenix.org/system/files/login/articles/105516-Br...
Agreed. Bitcoin already has a built in transaction scripting language that is deliberately not Turing complete. Most of the issues actually stem in terms from timing and synchronizing with external variables...not the limitations of the scripting language. For example, for a while it was believed you could make cross-chain contracts secure (without a trusted third party) but, afaik, nobody managed to work out the sub…
Earlier quoted context omitted.
Because OP doesn't understand why bitcoin "script" is limited in first place.
OP understands better than many of us why and how Bitcoin works. Script execution is limited by the fee (which is paid upfront). If the contract is paid to take 10 ops and 2 slots, if it uses more than that or takes longer than 10 ops to execute, it will be aborted and money will forever be locked.