Comment by Jabanga | Hacker News Reader

Comment by Jabanga | Hacker News Reader

Parent Full thread

>I need to at least mention that, well, this project is probably a bomb and you should be really careful with it. I, at least, wouldn't want to be the next DAO dev (e.g. project takes off quickly, unseen exploit exists, I lose some 10's of millions of other people's money) at mostly a personal (I'd feel guilty) and career trajectory level.

>The Parity multi-sig bug occurred in a solidity shop that was founded by the father of the language itself. It got past a serious audit and had the best eng process known (for solidity) enforced. The odds that your code -- currently unaudited correct? -- doesn't have an exploit are, while impossible to accurately calculate, quite remote.

I think this is very inaccurate. There have been devastating bugs in Ethereum, namely the bug in the DAO and the one in the Parity multisig contract. But there are numerous smart contracts that have not been found to be vulnerable. You cannot extrapolate what happened to two contracts to the entire ecosystem. It's inaccurate to claim that the probability that the loan contract he's working on will not have critical bugs once it's live is "remote", and a red herring to point out that it is unlikely to be bug free now, when it is still in development.

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's not imprecise to say that a more complex code base that didn't follow the best approach available likely has a bug.

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.

Reply on news.ycombinator.com