Ethereum to implement hard fork to save funds stolen from The DAO
As experts say, ethers being drained from The DAO’s account are relatively safe because the hacker will not be able to withdraw the funds for another 27 days.
At an emergency meeting of the Ethereum Foundation members, it was proposed to implement successive soft and hard forks to deal with the consequence of the cyberattack on the investment platform today, the project’s blog reports.
The attack is still under way as the hacker keeps draining the cryptocurrency from The DAO to one of the child DAO’s created using the platform’s split function. The attacker calls the split function recursively inside the original split thus collecting ether repeatedly within a single transaction.
The good news is that due to the platform design, even if no measures are taken, the attacker will not be able to withdraw the stolen tokens from the child DAO at least for another 27 days.
The developers suggest using this time to first implement a soft fork, which would not reverse any transactions or return the funds but prevent the stolen tokens to be withdrawn past the 27-day window. A hard fork will follow that would allow the original token holders to retrieve their ethers transferring them to a withdrawal-only smart contract. However, the final decision as to the rescue plan belongs to ether miners who are to vote for or against the solution.
Ethereum developers advise miners to carry on their operations as normal and wait for the soft fork to arrive, ether users to keep calm and exchanges to resume trading in the cryptocurrency, as “Ethereum itself is perfectly safe.”
The news came this morning that The DAO investment platform was hacked and ether tokens drained from its account to the amount now exceeding $53 mln. The price of ether has fallen to $15 per token, while developers asked exchanges to suspend ether trade.
We are coinfox.info //
We hope that you will appreciate our work.
We will be happy to hear your comments and suggestions.
Follow us on Facebook
It's not a certainty a hard fork will be implemented. Some people believe in decentralization for decentralization sake no matter what happens to the people or the community interests.
I think trust is very important and maintaining trust is important enough in these special circumstances to do a hard fork. The percentage that the hacker would get in ETH is too high, the possibility of it being an inside job is too high, it's not ethically acceptable to allow hackers to be rewarded because it sets a precedent which could create incentive for hackers all over to find exploits and rob smart contracts.
If one hacker can get and keep over 100 million dollars with a simple exploit like this then what kind of lesson will others learn?
Not to put money in unsafe smart contracts
All Turing complete smart contracts are fundamentally unsafe. This is because at the deepest levels they cannot be logically consistent. This means you cannot get a clear yes or no answer as an output so the behavior is never exactly as expected. This unexpected behavior is the cause of bugs.
The only real answer is to have functional decidable language security where you have consistent logic. You have to give up completeness in exchange for consistency always. But you get the benefit of not having code which does unexpected behaviors which means no more bugs, no more underhanded stealth logic bombs, no more zero days, none of that is possible because just as with propositional logic you have a true or false certainty at all times.
Turing complete imperative languages can never be trusted. What you get is an approximation where you through trial and error, testing and other methods refine the code base over time. For smart contracts where you can't easily do that you have to get it right on the first time and when lots of money is involved you don't want to have to trust the programmer not to sneak a logic bomb into the code.
References
http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
That makes the decision whether to put money in them easier doesn't it.
The other viable option is to embrace Turing incompleteness: