Quote from: PhantomPhreak on February 04, 2014, 02:40:57 PM

I'm quite sure that the benefits of building on Bitcoin, not the least of which are much increased development speed and security, do indeed outweigh the costs.

To expand on this a little, the biggest danger with Ethereum is that its scripting language is Turing Complete, and so it's defenses against any exploit conceivable are only as secure as the sandbox that contains the running scripts.

Here's an interesting discussion thread on the topic of Ethereum vs Bitcoin.

The post below by Adam Back is kind of a TL;DR about the dangers of Ethereum (though don't miss Gavin Andressen and Vitalin Buterik duking it out a bit further down the thread):

Quote from: adam3us on January 26, 2014, 01:35:47 PM

From another thread:

Quote from: Peter R on January 26, 2014, 08:10:46 AM

Thanks d'aniel. My initial feeling is that Turing-completeness is not necessary for bitcoin and would very likely lead to unforeseen problems and instability (mostly related to the halting problem). Money isn't a computer.

They [meaning Etherium] address halting by fee paying for interpreter cycles. When the fee runs out the contract is stopped.

But there are obviously interpreter escape dangers, which are harder to contain for a stateful, looping, low level (byte code like) language. Look at the history of java sandbox escapes. People say that was mostly due to call outs to complex native library have to look through the (large!) CVE database on JVM to figure out the stats. Also the pressure may have been lower. If you get real money under it all kinds of resources and unrevealed 0-days can leak out of the woodwork and create the new target for grey and black hats some of whom are world class at this stuff. Or even from national security network intrusion insiders with Snowden-level access or the people developing and selling grey market 0-day to the intelligence community etc. Those people are fallible humans too - they may succum to the financial motive, or the people who developed and sold them the 0-days may find a new monetization model, or second use for them (they cant "forget" them after sale).

There have also been VM escapes from full hw abstraction vms (i mean not just API sandbox light linux-in-linux virtuozzo but actual whole OS in the container).

And finally bitcoin scripting is functional, stateless and non-looping (non TC in fact also) for a reason. Bitcoin doesnt (and I think its intentional) have even extrospection. There are grey-goo outcomes if you are not careful with even something as constrained as an extrospection op code to existing language. There will be whole classes of not yet imagined grey goo opportunities lurking in a full TC language. You cant easily systematically defend against whole classes of such issues without intentional constrained language.

Here's a thread started by Greg to explore grey-goo outcomes from extended scripting:

https://bitcointalk.org/index.php?topic=278122.0

Greg Maxwell also noted the elevated risk of forks developing. If there is any deviation in script outcome and being more complex there is more risk there also. eg tracking how many cycles through a JIT executed/CSE optimized etc version as super-majority of nodes MUST interpret the script to the same byte code instruction, or one version can return true, another false etc.

I discussed these risks with Vitalik and he is a very smart guy, so obviously they'll try to do what they can to contain them, but you know bitcoin is the highest assurance sw dev and QA risk on the planet by orders of magnitude. So it maybe a time for risk containment rather than risk LoC and API size expansion, I am already worried on bitcoin about base band-processors hacks, 0-day OS and CPU hacks, and thinking a more zero-trust more air-gap model needs to be the objective.

If hypothetically ethereum grew to large adoption (litecoin level say) and then there was enough motivation and something failed hard, there are potential whole system value loss, hard fork and other failure modes. It seems to have by design, ongoing higher surface area security & value safety risk

Also btw Dan Kaminsky said he spent 4 months trying to hack bitcoin (network stack, overflow on messages, the usual host-security 0-day discovery process) and he failed. He's one of the best host security guys and the experience impressed him. Its not a simple thing to make a network stack that bullet proof, most even hard core programmers cant do it. You probably have to practice 0-day development to some depth to even understand fully the risks and defense landscape. Bitcoin got there with a really solid start from Satoshi and a bootstrap period where other bugs were fixed before the pressure built up to $10b.

I am not going to comment for now on the funding model

They are somewhere between the others and I am sure Vitalik has his eye on actual innovation as well, because knowing him he lives for tech challenge.

I think anything that needs to be done, can be done in a bitcoin centric backwards compatible evolutionary way using eg 1-way peg and other related features while maintaining value firewalls between long term holders and people using newer features.

But clearly other than the security containment, zero-defect in flight once live, and grey-goo risks, Ethereum can create some fun self-extensibility with a loose analog of like introspection, late binding, eval and dynamically loadable code languages. We do have to be clear that the cost is the towards opposite end of the spectrum, though lower than activeX and executing native code delivered over the network. Fun possibilities but a big security job.

Adam