| I had a long discussion about this topic here: https://news.ycombinator.com/item?id=14807779 > I think this is very inaccurate. Perhaps, though keep in mind I did say that it is "[the odds that this code has a serious bug are] impossible to calculate accurately" and there's a reason for that. I'd argue that it wasn't an imprecise statement. Gavin was the father of solidity, put in the process at Parity, had an audit team, and the $200M multi-sig bug still got through. If the top-tier team and process failed, it's not imprecise to say that a more complex code base that didn't follow the best approach available likely has a bug. This is invariant on the phase of development. Moreover, I was cautioning OP to be careful. One valid response to that is what he's already going to do (get an audit). This makes a bug less likely. The next phase would be a Bankor-style pilot+bounty. After that... well we just don't know. > But there are numerous smart contracts that have not been found to be vulnerable. Sorry, but unexploited is not unexploitable. Many/most of these contracts are probably unexploitable, but the problem is that we can't be sure. To me, smart contract construction on the EVM/Solidity is closer to a "rolling your own crypto" grade problem, which is something that after years of massive exploits we've all agreed that you do not ever do it, vs building a webapp. Long term as tooling + approaches + standards + the language itself mature, it'll come closer to "backend programming at a hedge fund/bank" where it's doable but you need to be responsible. |
It is imprecise because the Parity multisig bug is an outlier. There are numerous contracts both by 'crack' teams like Parity, and by teams with a less established reputation, that have not been found to have a critical bug in production.
Therefore, the evidence that most contracts have serious bugs is simply absent, and one can't accurately state that the odds of a contract being launched without a serious bug is "remote".
>Moreover, I was cautioning OP to be careful. One valid response to that is what he's already going to do (get an audit). This makes a bug less likely. The next phase would be a Bankor-style pilot+bounty. After that... well we just don't know.
Yes and I agree with your advice.
>Sorry, but unexploited is not unexploitable.
And the possibility that it is exploitable does not mean it is exploitable. I'm not saying that it's out of the question that there are numerous contracts out there with exploits. I'm saying that we can't assign a probability to that being the situation.