- “I find this incredibly troublesome and it sets an insanely dangerous precedent. Today we are bailing out friends who made a bad decision to participate in a poorly written contract, tomorrow every oppressive state in the world will be wanting their list of transactions and contracts blacklisted. Either we accept turing-complete contracts with their consequences, or we admit the Ethereum platform is a failed experiment and the concept of purely mathematical smart contracts is simply a fantasy that cannot work in the real world without the support of the current legal system. The later would be a real shame. I personally don't support compromising any network with a hardfork to recover my friends lost value. It's irresponsible and dangerous.”
As time goes on, hardforking or softforking for individual cases is going to become increasingly difficult. Bitcoin has done it in the past, but probably won't going forward. From a point of principle, I don't think token holders of The DAO deserve special treatment. However, there is little doubt that the network in general will do better to put this behind them, and a fork is the best way to do that. I'd be perfectly happy if the stolen eth was sent to an irretrievable address. These are still very early days. Ethereum hasn't yet implemented a number of scheduled hardforks. Embarrassing learning experiences and forks now aren't going to destroy faith in the network. Mich of the fault lies with slock.it. They rushed forward irresponsibly. However, many of the devs are DAO curators., including Buterin. They did not push back and advise more caution.
Further discussion amongst the forensic analysis of the vulnerability (I'm talking about Phil Daian's work I linked in the other thread ) suggests it's not just the DAO code that was poorly written but some fundamental assumptions about Solidity which led to the problem and could in future cause problems with any code that calls external code. On the one hand there is a deep discussion about whether blacklisting/whitelisting ethereum contracts and addresses goes against the raison d'etre of ethereum and on the other hand whether the design of the language itself is flawed. Whether these issues nullify the legal gambit of the attacker or just muddy the waters further, who knows.
After reading Phil's post, I don't think the design of Solidity is wrong per se, but that there needs to be more flags for developers intending to call external functions. I am sure that a lot of work is going to go into 'best practices' here after this event.