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.
>> 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.