In this context, inflation and deflation are commonly understood to be the ratio between supply and demand of the currency. Assuming significant adoption and any economic growth, demand for BTC will increase faster than supply, hence deflation.
Same, though it's not actually inflationary either, but equilibritory [1].
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.
Another Bitcoin crypto-clone. Why does this need crowdfunding? Is the traditional mining and conversion to other cryptocurrencies not enough of a financial reward?
I'm sure some crowdfunded projects have ended up being mis-managed but that isn't a very fair statement to leverage against these guys (if you don't know them).
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.
But these fees are only paid to miners— not all the other nodes validating the transactions. If only miners validate, what will keep miners honest (e.g. from writing themselves a blank check for more coins).
That's the same argument about non-mining Bitcoin nodes. Those who choose maximum security have to perform thousands of ECDSA checks and store the whole blockchain. For everyone else there's Masterc... mobile app. Your argument is valid, but not (imho) specific to Ethereum.
The distinction for Bitcoin is that a smartphone can keep up with the maximum possible computation load from validation.
The design is very purposefully limited to keep the validation computation so cheap that it is effectively free, and no amount of fee paying can convince miners to allow more computation since the limits are a property of the system enforced by all nodes just as the supply of coin is limited.
I think it's a less useful mental model to think of what Bitcoin is doing as execution. What a Bitcoin script is really is a witness of an execution that the signer performed— proof that he executed it faithfully— rather than the computation itself. It's just a product of engineering that the simplest (to implement) way to verify execution is to perform it again, but its not intrinsic.
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.
This is difficult, because you need to check the computation. (The whole point of distributed cryptocurrency is that you do not trust your peers.) Only those computations that are hard to compute but easy to check can be used by cryptocurrencies, not any general useful computations.
Interesting that you pick that, it would be more meaningful if TLS/SSL was not vulnerable to man in the middle and certificate spoofing (respectively). The security is useful, but is it sufficient? Sure searching for hash collisions provides a use, but would it not be interesting to devise a way to provide proof of work for a problem that had more useful results. A good example would be solving satisfiability problems posed in previous blocks, it is easy to calculate the difficulty of the problem and the solving solution is not much better then trying random solutions and hoping and the results is instantly verifiable. It would let people encode meaningful problems to be used as proof of work.
If the devs are reading--the quotes scroll too quickly to comfortably read, especially with no way to control them or go back. Otherwise this is a gorgeously designed site.
Also, I would do away with clichés like "the only limit is your imagination" et similia as well as all the techno-babble. Keep it simple, don't overdo it.
It seems there's a nice economical limit on script execution. If the contract during its executing consumes more resources (ops + memory) than fees attached to it, the it's simply considered invalid. That computation is done after the money is locked and the fee is attached, so if you do while(1){}, you are basically donating to a miner.
I haven't finished reading everything yet, so I maybe totally incorrect. But I doubt Vitalik didn't consider these issues.
I am less worried about while(1){} and more about viruses (either in-system or breaking out of it via exploits) roaming the blockchain semi-autonomously stealing or spying.
Ether scripts are not operating in unrestricted environment. They are turing-complete, but their environment and available memory are very restricted. A bug in the implementation may lead to denial-of-service attacks (just like similar bugs in Bitcoin), but it does not mean there will be ether viruses spreading through the network. At worst, it could be a global DoS issue that can be quickly fixed and the entire history reversed right before the problematic transaction.
I do not share your optimism. The worst case is autonomous viruses that steal to sustain their transaction fees and escape their jails to wreak havoc via buffer overruns or other similar exploits.
Those viruses would have to exploit some bug in implementation, right? Once the bug is found, all bad blocks will be thrown away. All valid transactions will be included in new blocks.
I don't think script complexity would be the biggest obstacle to adoption, but other factors. For one, advanced script upgrades to Bitcoin that preserve existing BTC distribution of wealth would be more welcome than something from scratch. It'd be safer alternative in the eyes of the bitcoin holders, who would not need to diversify into altcoin.
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 subtle race conditions.
See the protocol diagram here: https://bitcointalk.org/index.php?topic=321228 (alice and bob can be played by the same party for a cross chain transaction). There are some additional timing considerations for reorg safety when multiple chains are involved, but simply delaying all chain operations by enough blocks to make a reorg infeasible should be sufficient.
Well, it depends on context. In Java, they're factories. The more general term seems to be "platform". For the world of cryptocurrencies, I'd propose "mint".
I have to admit some of this sounds very powerful. I think the alternative block chain applications are more powerful than bitcoin.
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.
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:
Cuckoo Cycle at https://github.com/tromp/cuckoo seems like a better proof-of-work system and comes with a full implementation.
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.
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.
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?
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.
A hybrid system sounds reasonable, but I'm more interested in how they think that Dagger is ASIC-proof. I can't tell without a real description of the algorithm, but what is presented doesn't seem hard to parallelize.
"We have made a preliminary decision that we likely will fund a contest, similar to that used to develop AES and SHA3, to determine the best ASIC-proof (ie. going beyond just "memory hard" as a heuristic) mining algorithm"
http://www.reddit.com/r/ethereum/comments/1vh94e/dagger_upda...
Looking at the very bottom of that page, I do not understand how that function would prevent ASIC mining from being significant. You still need to compute a huge number of (SHA-3) hashes, and speeding these up could still make a significant difference, couldn't it?
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 ;-)
I'm glad to see that new altcoins are making this sort of design decision. To me BitCoin's amenability to ASIC implementation is a serious design flaw (for the reasons outlined on that page).
This seems to be a design flaw, not an implementation flaw.
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.
67 comments
[ 2.9 ms ] story [ 127 ms ] threadOther 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.
[1]:http://dictionary.reference.com/browse/equilibratory
The design is very purposefully limited to keep the validation computation so cheap that it is effectively free, and no amount of fee paying can convince miners to allow more computation since the limits are a property of the system enforced by all nodes just as the supply of coin is limited.
I think it's a less useful mental model to think of what Bitcoin is doing as execution. What a Bitcoin script is really is a witness of an execution that the signer performed— proof that he executed it faithfully— rather than the computation itself. It's just a product of engineering that the simplest (to implement) way to verify execution is to perform it again, but its not intrinsic.
"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.
This is a bit like saying, "I wish the computations in TLS/SSL did something useful besides securing the connection". The security IS useful!
* 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. :)
[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.
I don't think script complexity would be the biggest obstacle to adoption, but other factors. For one, advanced script upgrades to Bitcoin that preserve existing BTC distribution of wealth would be more welcome than something from scratch. It'd be safer alternative in the eyes of the bitcoin holders, who would not need to diversify into altcoin.
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.
My opinion is that we need some better generation currencies that are extremely hard to scale for mining before doing advanced stuff with them.
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
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.
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?
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.
And now they've stated,
"We have made a preliminary decision that we likely will fund a contest, similar to that used to develop AES and SHA3, to determine the best ASIC-proof (ie. going beyond just "memory hard" as a heuristic) mining algorithm" http://www.reddit.com/r/ethereum/comments/1vh94e/dagger_upda...
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 ;-)
Oh boy! Exciting!
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.