Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not an expert on Bitcoin's scripting language, but here's a few main takeaways

* Ethereum allows shared state between transactions, Bitcoin doesn't. That means one application can state "The price of Eth is $10USD" and a totally unrelated application can reference that value. The result is that each application provides an API that all other applications can call.

* Both Bitcoin and Ethereum have a stack based scripting language. However Ethereum also has a higher level language that compiles to the stack based language. That means you can right reasonably readable code without OP codes. Functional program is so much mentally easier than writing a stack

* Ethereum (unlike Bitcoin) is Turing complete. It can have code that loops and recurses based on the state of the chain



> Ethereum (unlike Bitcoin) is Turing complete. It can have code that loops and recurses based on the state of the chain

Yikes. Turing-completeness is the last thing I want in a contract language. These things should be _provable_ and _total_. Allowing arbitrary computation opens up a whole new can of worms.


This was my first reaction. Why does a contract language need to be Turing Complete? Trustless contracts + Turing tarpits seems like a big turn off to me.


People are working on formal verification of solidity code: https://forum.ethereum.org/discussion/3779/formal-verificati...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: