Ethereum Development Reality Check
bitcoinist.net
bitcoinist.net
> smart contract programming is complex and at the moment is lacking functionality
I disagree. Smart contract programming in the Solidity language[2] is already remarkably simple, and there are great tools like Truffle[3] that provide you all the necessary scaffolding for rapid iteration.
While it's certainly true that there are challenges and limitations in smart contract programming, as I discuss in my reddit post, that's not the same as "lacking functionality". There are many things that are already easy to do, and the limitations are because we're working at the cutting edge of technologies that are still being actively researched.
> Homomorphic Encryption
This is a nonsense red herring. It would be cool if someday we had homomorphic encryption, but it's not going to be ready on any relevant timeline, and the "lack" of it is absolutely not a problem for Ethereum.
> Once the transition to Proof of Stake occurs, however, will the Ether coins have to be re-issued?
What? Of course not.
This article is trying very hard to turn a discussion of future research directions into FUD. 0/10.
[1] https://www.reddit.com/r/ethereum/comments/4945us/can_we_hav... [2] http://ethereum.github.io/solidity/ [3] https://github.com/ConsenSys/truffle
However it does look cool and I'm open to the idea it makes sense somewhere, but I'd be interested to know where that somewhere is.
* No guarantee of transaction execution
* Turing-complete smart contracts are slow
* Scaling is a moonshot
* Oracles break the trust model
* Public blockchains struggle to stay decentralized
More here:
https://makebitcoingreatagain.wordpress.com/2016/02/10/5-cha...
I am amazed at this open contribution and collaboration.