I think we'll see a lot of interesting blockchain stuff come out in the next year. Recently, I have been trending toward the idea that one thing Bitcoin got right was carving out its useful domain area and focusing on that when it came to opcode support.

It seems to me to be much easier to reason about a very limited set of actions than the virtually unlimited ones Ethereum offers.

On the other hand, it's incredibly fast to spec out and deploy one of these contracts, which is pretty amazing to me. Lots of interesting things coming.

> The Ethereum virtual machine has to be completely error free if any sane person is going to put their money into it. I just don't see that happening.

Bitcoin also has a mini VM and scripting language (transactions are verified by "concatenating" the script of an output with the script of an input and running it). One big difference is that Bitcoin's scripting language isn't turing complete (e.g. you can't have loops or recursion) and there are other limitations like a per block limit on expensive operations (signature operations to be precise).

> The Ethereum virtual machine has to be completely error free if any sane person is going to put their money into it. I just don't see that happening.

Your fear seems to stem from misunderstanding how Ethereum works or what it even is.

Most likely, Ethereum itself (the "engine") will be effectively error-free - probably as good as the Linux kernel - once it reaches 1.0. And smart contracts can be as simple or complex as you like. If you're afraid of bugs, don't put money into any complex smart contracts. If there's a lot of money involved, then spend some money/time reviewing the smart contract.

Also, contracts can set precedent once they are in the ecosystem. If a contract has been heavily used prior to your desire to use it, you can copy it, and be relatively confident that it will be secure for you to use.

>Most likely, Ethereum itself (the "engine") will be effectively error-free - probably as good as the Linux kernel - once it reaches 1.0.

"will be effectively error-free" != "probably as good as the Linux kernel", not even close :D

The security history of the JVM suggests that one shouldn't be optimistic there either.

counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)

Funny, most pwn2owns there are multiple successful escapes of any of a number of js sandboxes. I hear about it at least yearly, if not more often.

JavaScript has several mature, thoroughly scrutinized implementations. Ethereum has one brand new implementation.

To put it mildly: There will be blood.

There are actually eight different implementations at this time, although the go client has a slight majority of users according to ethstats.net

http://ethdocs.org/en/latest/ethereum-clients/index.html

There are at least two ethereum implementations, the main one and one in Rust.

JavaScript doesn't run on the JVM.

thanks for saying this, sometimes I'm like "wow" on hackernews comments, because you kind of assume people know what they're talking about but then its like not really.

I know that Javascript isn't run in the JVM, my point was that it's possible to write a virtual machine that doesn't get exploited every 5 minutes.

the JVM is a bit special because there are a large amount of escape hatches, native code and a complex trust model, which has caused a lot of the exploits you end up seeing.

But. JS was designed with this in mind, and has been tested for it for years. It's actually one of the greatest strengths of JS, but I imagine it was a lot of work (except, perhaps, maybe functional languages).

The linux kernel is and has been pretty buggy, especially by cryptographic standards.

Hopefully a lot better than the Linux kernel: http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html...

Linus doesn't view security bugs as a special category of bugs. So he doesn't prioritize them they way most infosec people would like them to. The lack of a strong security advocate in their leadership is largely the reason why Linux isn't the best example.

The other big reason being that it's a giant blob of C and a large attack surface.

All of these factors could be easily avoided or simply don't exist for an Ethereum contract developer.

don't forget the fact that he was approached by the NSA to insert backdoors into linux, a fact his father testified to on the record before EU parliament[0].

0. http://falkvinge.net/2013/11/17/nsa-asked-linus-torvalds-to-...

> effectively error-free - probably as good as the Linux kernel

I encounter major glaring issues as well as continual regressions in the linux kernel on weekly basis. I don't even know what you mean by as correct as the linux kernel

Ethereum faces a similar situation as counter-terrorism: There only needs to be one sizeable incident that slips through the cracks for confidence to be shot.

To top that off - a relatively simpler Bitcoin software is maintained by a team of well known developers with all the typical artifacts and cycles associated with enterprise software development - release notes, testing etc etc.

I'm sure the Ethereum team does the same but then when it comes to DAPPs and Contracts running on their VMs and potentially trying to compromise the underlying system things are way too fuzzy for now.

> The Ethereum virtual machine has to be completely error free if any sane person is going to put their money into it. I just don't see that happening.

Are you aware of the $155M USD people have sent to https://daohub.org using (depending on) Ethereum?

Are you aware that the Dao was created by employees from slock.it and the Dao's first project is to fund a project from slock.it?

Anyone who did 20 minutes of due diligence would be scratching their head at this.

Yes. I don't think they put in $155M, though. Which means they can't force such a project through unilaterally.