Deleting $300M by messing around with Ethereum contracts
hackernoon.com
hackernoon.com
I can imagine someone out there is pretty unhappy with him.
As well, if they do have any money, he just needs to delete it.
I don't think it's impossible, but it's clearly in conflict with the "release early, release often" culture. If anything, developing smart contracts is more like building software for NASA crafts : you have to get it right before the launch. And even regarding the NASA, I guess they still have room for some remote patching. In smart contracts, perfect is not the enemy of good, they are actually synonymous.
Ironically, the article you link to does not support your post: it also stresses the difficulties of applying formal methods, and claims instead that various interventions of the sort that have not been particularly successful in securing software generally will be sufficient to satisfy the particularly stringent requirements of a crypto-currency (of course, to say that Ethereum needs formal methods in order to be usable would be to admit that it is not close to being so, so that view will always be contested by the Ethereum foundation. At Cardano [1], however, they do seem to think formal methods will be part of their solution, though I am not sure to what extent.)
This is all mostly moot, however, as the Ethereum we have now is demonstrably insecure by any measure.
However it comes with a range of problems, and often its not worth going into the effort of formally verifying a contract. But with ether, the costs quickly outweigh the ptential losses.
I don't know if it will work, in theory it can, i just wanted to be possitive: I see a light at the end of the tunnel.
If someone can accidentally delete that volume of your money, it's not that someone's fault, it's your fault.
Sure, but they're written in ways that humans can generally roll back a mistake and if two humans disagree about what should be done (due to a 'bug' or inconsistency in the contract) there are processes where a third human can listen to their arguments and decide what sounds like the most reasonable course of action. At no point is the code written by programmers the final arbiter of what the 'correct' course of action is.
0. http://www.telegraph.co.uk/news/uknews/crime/11414191/Hacker...
Secondly and more importantly, the fail-safes built into the system largely work. In the Bangladesh case for example the vast majority of the money they where attempting to steal was never transferred due to humans intervening and overriding the transfer order. And even a non-trivial amount of the money that was transferred was later recovered by reversing the transaction.
Additionally, for the love of god, why are people experimenting on the main-net? My understanding was Ethereum has a test-net to try and experiment/learn smart contract coding. Is that too different from the main-net to learn stuff?
Though looking at the screenshots, specially in the third one, he claims to be learning. He was experimenting sending kill() and destroy() to contracts on main net.
If you deploy code to the ethereum main net, it is vulnerable to the world. The issue isn't that the guy was toying with main net contracts, the issue was that the contract was busted, and there was this room for problems.
Ethereum has been extraordinarily prone to these sorts of errors so far (see the DAO). As of now, the foundation is unstable and the stakes are high.
Even if the code reviewer is honest there are some economical problems: - Code reviewer will find a balance between time spent, amount to put into the time dependent 'bounty' and probability of a bug that didn't come up during review --> little-at-stake problem - If you force the code reviewer to put in a significant amount of ETH into the time dependent bounty you won't find any reviewers willing to work for you because of the huge risk for them --> risk problem
How would that have worked with the the Parity 'hack'? - Parity deploying their multisig contracts, having a bounty with code reviewers. AFAIK it wasn't even a bug but a not-well-deployed contract library. So the reviewers would have said that Parity should go on and deploy their multisig contract. Parity would have deployed it in a wrong way (as they did). The 'hack'/accident would still have happened.
If your time dependent contract was separate from Parity's multisig the reviewer would still get his ETH back after the time lock releases. Alternatively the reviewer's funds would also be frozen.
Hopefully formal proof of contracts will save us sometime. Alternatively blockchain with some governance scheme that takes care of something like that would also be useful. Wait a second... Am I describing Tezos? Let's wait for them to launch and see if that works better.
If this features continues to exist as part of Eth - it will not likely ever be used commercially.
Even the admins, experts and people working on it don't seem to understand it well enough for it to be safe ...