"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.
If you want to reduce the need to trust a single party you can also use a SchellingCoin system, described as a "decentralized data feed" in the ethereum white paper v2 [2].
[1] http://forum.ethereum.org/discussion/comment/180/#Comment_18...
[2] http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-...
Butekin’s answer to that appears to be that providing the information at the right format should also be an Ethereum contract: users (both participants of your option) would enter another secondary contract with a weather service and pay a small sum is the information is properly available.
> wouldn't there be strong incentives for man in the middle attacks to deliver wrong data?
Yes, but I’m guessing not more than now… Ethereum offers to automate and lower the cost of such contracts, i.e. replace back-ends. You can imagine testing services remain active on both sides, checking from a distinct source that payments match; that is already what is in place, it’s just a fairly boring activity at the moment.
(This is one reason why I think a lot of fancy contracts are best done using a quorum of external oracles, since you have no better security than that in anything that does external IO, and it's much more scalable (and works great in Bitcoin already))
[1] http://www.reddit.com/r/Bitcoin/comments/20oyes/brilliant_an...
And I am not saying these things because Ethereum is a super-magic-brilliant protocol that involves deep knowledge about thirty years of development in multiple fields; it's not. It's also an ultimately fairly elementary idea that I still remain surprised that nobody tried to seriously push before me. In fact, at least two other groups got very close in 2012-2013, and a few weeks ago at the payments innovation conference in Boston I learned that apparently the concept sans blockchain was around in the 1990s; but for some reason they did not take the idea to its logical conclusion.
Also, our implementation of GHOST does not in any way compromise the concept of global state; blocks are required to specifically include uncle headers in order to benefit from them.
Judging from the technical description [1] and the most recent version of the draft white paper [2] alone, I think the project would benefit greatly from more substantial input and expertise from the academic cryptography community. I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification.
To be more precise: The metered computation mechanism is a very clever solution for dealing with unrestricted computation and unbounded data storage, but their proposed solution does not convincingly address the inevitable increase in space required. Hand-waving about greedy subtree verification without actual numbers/scenarios that shows this could work at all (which would be very surprising to say the least) is not convincing.
In all a great idea, though. It would be great if it works out.
[1] http://gavwood.com/Paper.pdf
[2] https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft
Umm... that's exactly one of the issues that we're cargo-culting about the most. There are two general categories of solutions to this problem: technical increments (ie. a better constant factor), and fundamental cryptographic upgrades (eg. the stacktrace challenge-response concept we have been talking about on our blog). The first category we are not yet doing because we are following the well established advice of "don't prematurely optimize". The second category, well, that's why we're thinking of ideas like distributed blockchain storage, clever algorithms to force more people to be full nodes, and challenge-response protocols. There is also another idea I was thinking of, which I'll have a post up over the next week or two.
In the long term, we are already beginning the development of a very widespread collaboration with academic groups to try to tackle the problems in cryptocurrency, and at this point we fully expect we'll end up releasing Ethereum 2 at some point in 2016 which would take a lot of new cryptography into account.
Lamport's work make this connection obvious. He invented the Byzantine Generals Problem and wrote this paper: "Time, Clocks, and the Ordering of Events in a Distributed System", Communications of the ACM 21, July 1978 http://research.microsoft.com/en-us/um/people/lamport/pubs/t...
logical broadcast means: every node has the same state (time invariance). the only thing that matters is hashing power.
A garbage collected language is an improvement over possible memory leaks due to human responsible memory allocation, but I think a larger problem is most programmer's (very human) inability to separate pure from impure code. Languages with very strong type guarantees do it for you and give you the tools to protect yourself from a lot of problems that are common in any language from Assembly all the way through to Go (I think Rust is actually well suited as well since it has a better type system than Go, but I haven't used the language so I can't speak to that).
[EDIT] minor edits.
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
Also, here's a related past HN thread: https://news.ycombinator.com/item?id=7287155
