>> The problem is that his programming toolchain allowed him to make these mistakes.
This is not the right conclusion; it is too shallow. It suggests that the risks of smart contracts can be fixed with some changes to the programming toolchain, but no-one has ever made one that only produces secure code, and I think I can safely call that notion a pipe-dream. How, then, do we write code with the level of security needed by smart contracts, and in the volume needed for smart contracts to be useful, if they are to be publicly accessible like Ethereum? The fact is, this has never been done before at that volume, and we do not know how to do it.
> Just remember...
>> certainly you should not store any money in a hot wallet that you’re not comfortable losing.
But what does it take to be comfortable? Unless you are just going to take someone else's word for it, you would have to examine all the code, including the libraries and the EVM itself, and be competent enough in security to be comfortable that you had not overlooked ay risks. But the real problem is that this does not just apply to hot wallets, it applies to anything that puts your Ethereum at risk. So, in practice, 'being comfortable' means trusting a bunch of people you probably do not know well, and with no recourse if that trust turned out to be overly optimistic.
For whatever historical reasons, software has almost always been engineered shoddily as compared to other money-critical or life-critical forms of engineering.
Companies (and governments) aren't willing to make the investments of time, personnel, expertise, and money that are required to create secure, safe code. Insecurity and vulnerability is the norm even among supposedly security-conscious organizations.
We could discuss the root causes all day (companies rarely face full consequences of poor security, etc), but part of the problem is denial. Few are willing to acknowledge how much work it would be to create truly secure code. Instead they settle for being better than most competitors.
However, this does not mean that really, actually secure code is impossible, just that we should (a) admit the scope of the challenge, (b) start taking steps toward that goal (like investing more in research).
The people who proceed anyway stand to benefit handsomely if they don't screw it up. So the game is simply: don't screw up.
It's hard, to be sure. But to say it's impossible is to overstate the issue. And even if it is impossible, it doesn't mean it will end in disaster 100% of the time.
Actually, a lot of people seem to be in denial over just how difficult it is, and what those difficulties are.
> So the game is simply: don't screw up.
If only the people who lost a combined $31M had followed this simple advice! Then everything would have been fine.
> And even if it is impossible, it doesn't mean it will end in disaster 100% of the time.
It does not have to end in disaster 100% of the time for people to lose faith. Losing < $1M would do it for me.
This is just talking around the issue. There is a currently-unsolved problem here, and if you have a solution, it would be helpful if you were to share it.
It's daft in most contexts, and is one of the largest sources of security problems. If your design requires enumerating badness[1], you're doing it wrong.
> from: http://hackingdistributed.com/2017/07/20/parity-wallet-not-a...
>> Just about every ICO, trust and company used the Parity multisig wallet, and that code was considered well-tested.
-sigh- This is, unfortunately, a common problem. "It worked ok the last N times" and "It passed a lot of tests" do not mean it's bug-free and safe to use. Richard Feynman was right during the Challenger investigation when he called this a childish attitude. (He was also right in not wanting to assign blame, instead asking "How do we educate the child?"[2])
[1] http://www.ranum.com/security/computer_security/editorials/d...
https://github.com/nemequ/portable-snippets/blob/master/safe...
The real issue here is that the class constructor called a function instead of containing all code within itself. It's a fundamental misunderstanding of how the EVM works and how Solidity compiles to it.
I've read the code and it's hard to convey the level of incompetence that went into having a dynamic call from the Wallet constructor to the initWallet function; but it's very, very high.
> The problem is that his programming toolchain allowed him to make these mistakes.
Damn straight. The problem is that the model of 'public by default, opt in for security' is fundamentally daft in this context. There's quite a good read on that particular topic here too http://hackingdistributed.com/2017/07/20/parity-wallet-not-a....
...but hey, if this ends up making Ethereum better, more secure and more robust as a result, then that's a good thing; it probably does need a different better language to express code in.
Just remember...
> certainly you should not store any money in a hot wallet that you’re not comfortable losing.