Etherium sounds like a great idea, and a great approach. But I'm afraid it's going to end up like GPG: Technically awesome, strong, capable, and useful - but completely out of reach of most of the people you'd want to use it with.
Every time I read a "Getting started with Ethereum" guide which involves 7 steps just to buy Bitcoin (from a site nobody's heard of) and then set up a wallet, I watch the number of potential users dropping like a rock.
I hope very much that it succeeds enough to justify its learning curve, as it's an interesting idea. But I suspect that outside of a few very small markets where it offers the ability to do something completely impossible with any other method, having an ethereum interface for your product or service will be roughly equivalent to GPG signing all your emails: People in the know weren't that concerned anyways, and nobody else knows enough to care.
Someone really has to get a simple proof of concept application made that any dummy can understand and run on their own. I'm a developer that bought ethereum, and even after reading their materials after the launch I couldn't be bothered with trying to get it running or understanding it. That doesn't bode well for the long-term success of the project.
There are a few projects working on this. One problem is key management and giving the app a connection to the blockchain. If you do key management in the webapp and read from the blockchain via a centralized API, thats not much of an improvement over existing systems. Ethereum core's solution to this is a special browser, but it is still under development. I'm working on a project[0] that takes this on, but is still a couple months out from a public beta. Its a bit of a hack but it manages a zero-install solution by having a sort of browser-in-browser that intercepts transaction signing requests and provides access to blockchain data. Can't wait to get it out there.
Ethereum isn't ready for end users today. Remember that you used to have to wire money to Japan to get bitcoins. Today, you install an app on your phone, put in a debit card number, then deposit funds in the app to access the Bitcoin network, regardless if you hold the funds as dollars or bitcoins.
Give it time. Or better yet, help us! This technology is about to reshape the world.
Right now it's the "Frontier" release, which is intended for developers. Down the road they want a browser full of graphic apps, looking something like this: http://i.imgur.com/f4ha8Ho.png
Full disk encryption is (thankfully) becoming a bad example. Apple has been pushing it aggressivily and both iOS devices and Macs have full disk encryption by default.
It's a shame that it's not default on Windows or Android yet, but it unfortunately makes sense since they have to run on so many different configurations (unlike Apple which can ensure that everything running their OS' are capable of full disk encryption without a noticable performance hit).
I'm investing and developing a product on Ethereum, not affiliated with the project or developers, so I'll give my sense of things. We're in an era of rapid experimentation. It feels a bit like a shared developer box without any libs or tooling so people are busy working out the best way to approach common problems.
I know it sounds like marketing but it does remind me of the early days of the web, like 95, before the web was serious business. It's all toys and gizmos, the hacker equivalents to water ripple effects, with frameworks coming in to help people build more interesting and production-quality things.
Very basic questions persist such as how to best store large data files (ipfs looking like the clear winner), how to reference them, how to design a currency, how to avoid designs that are too stiff or get stuck in a state where they can't be easily updated, how to express an application model in smart contract form, how to best represent a user account, etc. If that sounds fun, jump in, if you were wanting something that matched the hype, wait a few months. Apps on Ethereum can be as expressive and polished as the apps you use today, and can even be designed just as centralized as the apps you use today, but with properties you would typically think of only belonging to Bitcoin.
I watched Ethereum for several months after the initial announcement and was really excited about it. I know the network went live recently and it surprises me how little it's been discussed at places like HN.
How are things going as far as tech, adoption, etc for Ethereum for those in the know?
I am curious how one goes about verifying that these "trustless transactions of arbitrary (turing-complete!) complexity" will have the behavior that you expect (as a participant) or intend (as an author) for them to have, and that they are proof from subversion by a malicious counter- or third party. After all, this is not exactly a solved problem anywhere else Turing-complete complexity is employed, and it would seem to nullify the point of trustlessness if you are relying on someone else's word on this matter.
Well, the compiled code is available, and if they provide the source code, you can verify that it compiles to the code on chain (or, you can analyze the code on chain without the source code of the contract, but that is harder).
The source code for the contract can be made to have a proof of correctness in it, or, as it is probably not all that long, if you look at the source code long enough you can be sufficiently convinced that it runs how you expect it to.
Regarding the problems with turing completeness, any transaction is guaranteed to finish within a particular number of steps, because the transaction includes an amount of "gas", which puts a limit to how many steps the contract will run. If it runs out of gas before finishing, all the changes in the state are reverted (but the person still pays the gas cost). If it finishes, then the extra "gas" is returned. (the transaction specifies some "gas cost", which is how much ether per gas or gas per ether (idr) , and some amount of ether, which is the max cost the transaction is allowed to take. There aren't "gas balances", any "gas" that is transferred just is ether at the end. Its just a unit of how much computation, and the gas price is how much they are willing to pay per amount of computation. I feel like I didn't explain this well...)
Checking that the contracts were run correctly is done by anyone verifying the block which contains the contract call. If the miner runs the contract incorrectly, then the people verifying the block will not accept the block as valid, so people won't mine on the block, so it wont end up in the main chain, so the miner will not receive anything from mining the block, and what happens in the wrong execution wont effect anything.
I'm not sure if this explanation has been very clear, but I hope it has been clear enough. I can try again if it isn't though.
Thank you for your reply, but I have to say that I think it understates the problem.
>The source code for the contract can be made to have a proof of correctness in it..
Has this capability already been implemented for the Ethereum contract language(s)? If so, I would greatly appreciate a link, as my admittedly cursory search did not find it (there is some discussion of verification of the Ethereum infrastructure, but that is merely a precondition to contract verification.)
Even so, I think it is significant that only a tiny fraction of today's software is written this way, and only a tiny fraction of all developers know how to do it. Someone has to write these contracts.
>... or, as it is probably not all that long...
Ethereum's promoters are imagining nothing less than a revolutionary new economy, with vast networks of interacting contracts. The amount of contract software implicit in these dreams is huge.
>If you look at the source code long enough you can be sufficiently convinced that it runs how you expect it to.
The steady stream of security vulnerabilities that are being found in ordinary software shows that this is not an effective technique. If you are a software developer, imagine doing your work in an environment where any bug of yours could cause you, personally, to lose a significant amount of money.
Nor do I think 'gas' completely solves this problem. Now your analysis has to cover the issue of whether your contract, or any of those it is dependent on, will run out of gas before completion. In most cases, and particularly in networks of dependent transactions, reverting back to the initial state is not a viable outcome (imagine that happening on the last payment of your mortgage on a house.) I can imagine that running out of gas on some obscure corner case might be used by an attacker as as a means to disrupt a network of dependent transactions.
Afaik, no, proofs of correctness are not currently implemented in the languages that are used. Some of them iirc have a way to do that in part, but currently the languages aren't set up for full proofs of correctness. (But, iirc, some things can be shown)
It is planned though.
Ok, yes, I suppose that the contracts will/would eventually get kind of long. As it is now though, It hasn't taken me /all/ that long to read the contracts I've looked at. (But perhaps I've only bothered to look at the ones short enough to read )
Regarding finding security flaws despite people looking carefully: yes, that seems a good point. I think proofs of correctness will be important for important contracts. However, many contracts logic is not really all that complicated. A contract can be powerful without being complicated, I think. Because of this, I think much of the time the proofs should not be too hard to write.
Regarding running out of gas:
Well, yes, if the transaction you send does not have enough gas, and you needed it to run, that could be a problem. But, if you run the transaction locally, and use that to estimate the amount of gas which needs to be used (might not be exact if the state of the contract changes in a way that your transaction needs more computation, but for reasonable contracts I think this would not be much), and one can provide extra gas in case this happens (the extra gas will be refunded), to have a high confidence that it will be enough.
But, if the transaction is important, one would be watching what happened carefully anyway, to make sure the transaction gets in the chain, regardless of the complications from the computations in the transaction. If, counter to your expectations, the gas you provided did not end up being enough, then you would be able to notice this, and, though you would be out that gas cost, you could just send the transaction again with more gas.
The block times are very short (under a minute), so you probably wouldn't have to wait long to send the transaction again with more gas. Most of the gas costs shouldn't be too large, so unless the transaction you are sending is very time sensitive, or very computationally expensive, a transaction running out of gas shouldn't be /too/ much of a problem?
I think you make some good points btw, just explaining my understanding of how those things are addressed.
Also, I'm not sure, but it seems you might have a small confusion about gas. Gas is included in the transaction, not stored by a contract over time. Gas only exists within the context of a particular transaction, the token which is actually exchanged is ether. You might have just been choosing not to mention the details of that though.
I think @mannykannot misunderstands the purpose of gas in Ethereum. It's only purpose is a solution to the Halting Problem [1]. Alternative solution could be disallowing jumps backwards / loops or limiting time of the computation.
Why is it the problem? Because contract with something like while(1){}; will render the entire network of nodes useless.
I'm interested in it, mainly as a tool of regulatory arbitrage. I chiefly find it interesting as a means of making decentralized prediction markets. Our governments don't seem to want to allow the innovation. However, if we can get a decentralized Prediction market liquid and running, then I think there will be significant pressure for the government to legalize centralized prediction markets, which will be much more efficient.
You might be interested in http://www.augur.net/. Although, I believe it uses its own native token, rather than being built directly on top of bitcoin or ethereum.
Hey thanks for sharing our project on this post! Just wanted to clear something up from what you said.
Augur's native token is not what is used to create markets, Augur's token is Called REP (short for Reputation) and holders of the token actually serve as reporters that serve as the basis of our decentralized oracle system.
We created a few resources to explain how REP works including how REP holders are rewarded for reporting the truth/punished for reporting lies. We created a short two minute animated video to explain this process you can check out here: https://www.youtube.com/watch?v=sCms-snzHk4.
Additionally there is a great resource going into much further detail about Reputation as well as an infographic to visually illustrate the process here: http://www.augur.net/blog/what-is-reputation
Augur is built directly on Ethereum. Truthcoin will be making its own chain. I don't care who wins, and to be honest I don't give either a very high chance. I really really think prediction markets should exist though, So I applaud both efforts.
One real big problem is nobody wants to bet using shady highly volatile currency like Bitcoin or Ether. I'd much prefer USD markets, Vitalik has some ideas about making stable coins that track USD. Hopefully that works out.
the DAI project (originally eDollar, which is now intended to be built using DAI) which tracks a value which I think is like, some basket of different currencies, is being worked on.
I don't really understand the mechanism by which it is meant to track the price of the basket of currencies, but I haven't seen many criticisms of it?
It allows you to build incentive structures that are not centrally controlled. There is no server to raid. This comes at the cost of enormous scaling issues. However,it looks like it will be able to handle a market with about $500 million in volume per year - at this point I hope the advantages of prediction markets will be clear enough that centralized markets will be made legal. Centralized markets are vastly preferable in most respects.
Definitely a generalization but I think that's how it's viewed by many from 30k ft. I should have made it clearer that I was making an observation about a perception not my own views.
Every time I read a "Getting started with Ethereum" guide which involves 7 steps just to buy Bitcoin (from a site nobody's heard of) and then set up a wallet, I watch the number of potential users dropping like a rock.
I hope very much that it succeeds enough to justify its learning curve, as it's an interesting idea. But I suspect that outside of a few very small markets where it offers the ability to do something completely impossible with any other method, having an ethereum interface for your product or service will be roughly equivalent to GPG signing all your emails: People in the know weren't that concerned anyways, and nobody else knows enough to care.