This version contains some mistakes and approximations. For a more up-to-date paper you should take a look at the White paper v2 draft [1].
A more formal and technical description is presented in the Yellow paper (also draft) [2].
[1] https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft
The 2007 book Rainbows End by Vernor Vinge addresses this topic from a science fiction perspective. A major plot element is the ability of individuals to enter into "affliances": digital, automatically-escrowed contracts between individuals providing small services in networks created on-demand to produce larger-scale goods and services. https://en.wikipedia.org/wiki/Rainbows_End (copied my past comment at https://news.ycombinator.com/item?id=7287584)
Also, here's a related past HN thread: https://news.ycombinator.com/item?id=7287155
anyone who thinks GHOST is a good idea, has not understood Bitcoin at all. the whole point of the blocks is that nodes can work on the global state in a chain. so the idea that nodes should work on greedy subtrees is about the worst possible idea. Bitcoin solves not only the Byzantine generals problem, but a latency variance problem, to achieve logical broadcast. anyway, the author of this paper also believes that "anyone with reasonably high intelligence could have invented Bitcoin by random luck" [1]. well, no. there are many hidden problems which Bitcoin solves. the literature on quorum systems, distributed applications, etc. is very deep.
[1] http://www.reddit.com/r/Bitcoin/comments/20oyes/brilliant_an...
I can't decide if I want to see ethereum implemented in dwarf fortress ... or dwarf fortress implemented in ethereum ...
I hope they focus more on their Go client than the C++ one. Something like this needs to be as secure as it can get. No reason to have it vulnerable to memory leaks and such, if they don't have to.
Began reading on the tram home.. need to read up on basic crypto currencies
The explanation of all the opcodes for the contact script does not list any IO operations for external (non-storage) data (at least none that I could see). However, in the list of Ethereum examples, the following is given:
"Crop insurance. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well."
Does somebody know how the contract would be able to read a data feed? I did not find anything in the language spec. Such a feature would be really interesting. On the one hand it would allow for a ton of interesting options (binding contracts to stock markets, emails, political events) on the other hand how would a contract behave if the required data url is gone (i.e. the weather data feed changed from weather.php?v1 to /v1/weather). Whats more, wouldn't there be strong incentives for man in the middle attacks to deliver wrong data? This sounds like a very powerful yet dangerous feature, so I'd love to learn more about the spec and reasoning behind this.