Quote from: iamnotback on June 20, 2016, 12:36:34 AM

Can't blame this solely on Tual and The DAO:

Quote from: iamnotback on June 19, 2016, 08:55:21 PM

...

There are no safety mechanisms built into the SOLIDARITY. There was no attempt to do this incrementally. They released Turing-complete scripting into the wild knowing full well that it must blow up. Very, very unprofessional.

We can't blame this just on The DAO. The root cause starts with Vitalik and his delusions. Casper was another delusion that we knew would fail. How many months and $millions did they waste on that.

In fact, the flaw is in SOLIDARITY:

Quote from: http://pdaian.com/blog/chasing-the-dao-attackers-wake/

A fundamental flaw in Solidity

If you use the call construct in Solidity on external contracts, and if you have any externally-callable functions in your own contract that modify state, you cannot assume anything about the state of your contract after the external call is executed.

Quote from: Phil

Agreed, the call construct is OK if you know what code is running. If you dont though, as I said you can make no assumptions about your programs state or control flow when that call completes.

Quote from: Corbin

And this is why Im shocked that, of the concepts borrowed from the object-capability literature, Ethereum borrowed smart contracts but did not follow up with capability-safe language and VM design.

And I remember that his was a flaw that I had realized in 2014 would be in SOLIDARITY when I read they would support contracts calling other contracts. I knew over 2 years ago that this exploit would be possible.

Quote from: iamnotback on June 17, 2016, 12:19:03 PM

Follow-up:

https://bitcointalk.org/index.php?topic=1505886.msg15250689#msg15250689

Also note the current hack of The DAO is a reason I'd probably not prefer to build anything on Ethereum. I don't trust the code of those inexperienced, wide-eyed youngsters.

.. and I'm pretty sure it's also part in the Paradox thread as well... at least plenty hints and warnings.