Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deconstructing the DAO Attack: A Brief Code Tour

vessenes.com

Post reply on HN
Print view View original

91–100 of 167 posts

Re: Deconstructing the DAO Attack: A Brief Code Tour

#91

Post by legohead »

winteriscoming wrote: post #39

The apparent typo is odd, IMO. I don't know the language in which that program is written, but looking at that snippet, "Transfer" takes 3 arguments whereas the "transfer" function takes 2 arguments. Isn't there any code review involved when this makes into the codebase. Assuming there was some code review and the reviewer just missed it (which is very much possible), a basic unit test case would have easily caught t…

This is what I wanted to ask about. I don't even know what language this is. Is Transfer even a legit function, and if not, does this language just keep on chugging for non-existant function calls?

Re: Deconstructing the DAO Attack: A Brief Code Tour

#92

Post by vessenes »

pmoriarty wrote: post #88
tinco wrote: post #37

In addition to this the language is not explicit enough. Even standard Haskell wouldn't be safe enough for a program that manages $250MM directly without safe guards. In addition to typesafety, it would have to be both explicitly typed at the lowest possible granularity and annotated with pre and post conditions. Not only did this code allow a bunch of tokens be transferred without compensation, it left the whole acc…

"It's nice that Vitalik Buterin is a genius, but it shows that this guy is only 22 and dropped out of university because anyone with a degree in computer science knows about this stuff and its importance in high reliability systems." I wouldn't be so hard on the kid. Now, the due diligence that should have been performed by the corporations that sank millions in to this project, who actually do hire plenty of people…

Well, ​Dr. Chris Reitwiessner is in charge of the solidity project I believe.

I have been told he's not big on functional / richly typed systems, but I don't have any actual knowledge.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#93

Post by vessenes »

winteriscoming wrote: post #39

The apparent typo is odd, IMO. I don't know the language in which that program is written, but looking at that snippet, "Transfer" takes 3 arguments whereas the "transfer" function takes 2 arguments. Isn't there any code review involved when this makes into the codebase. Assuming there was some code review and the reviewer just missed it (which is very much possible), a basic unit test case would have easily caught t…

I think after sleeping on it that I agree with you, this is more likely the outcome of bad refactoring. You can read the code commits on github if you like; I don't have them handy, unfortunately.

transfer is a very poorly named function, of that there is no doubt. And Transfer is badly named as well.

transferAndLockTokens vs LogTransfer would be much, much better.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#94

Post by jstolfi »

winteriscoming wrote: post #51
niftich wrote: post #48

Earlier quoted context omitted.

I couldn't follow that Transfer vs transfer call either; the number of arguments don't match, and I don't know where 'amount_' comes from. The code is exceedingly painful to read, and makes me wish I had been involved in this effort before it made the news. I can't help but think, lack of unit tests aside, is this the first time they're running this code? What sorts of decision-making led to this outcome? I want Hanl…

If I understood the explanation on that article correctly, what's even more interesting is that this typo apparently hasn't yet been fixed in the repos (assuming I'm looking at the right ones). There are 2 repos which I looked at: https://github.com/slockit/DAO https://github.com/TheDAO/DAO-1.0 I don't know which one is the authoritative one. But the interesting bit is both these repos still have that same typo in th…

> this typo apparently hasn't yet been fixed in the repos

IIUC, once an Ethereum program is started, it cannot be killed or fixed. If so, updating the gitbub repo would be pointless at this time.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#95

Post by amaks »

The biggest problem I see with the code at https://github.com/slockit/DAO/ is absense of the unit tests. The code looks complex, how the hell can you make sure that it's right?

The Solidity wiki doesn't have a single entry on testing either:

https://github.com/ethereum/wiki/wiki/The-Solidity-Programmi...

Re: Deconstructing the DAO Attack: A Brief Code Tour

#96

Post by dang »

fabled_giraffe wrote: post #49
tinco wrote: post #29

Earlier quoted context omitted.

I think maybe you're a bit confused about what HN is, it is a community that gathers and discusses news that is relevant to people who are starting or funding new companies, mostly in the information technology sector. Cryptocurrencies attract money and spawn companies, there are YC funded startups that are based around cryptocurrencies. If you're looking for refuge from them, you've gone to the wrong place, this is…

> it is a community that gathers and discusses news that is relevant to people who are starting or funding new companies, mostly in the information technology sector. Been here since 2007 off and on. Usually don't use same user because I quit HN periodically due to philosophical differences, and I don't care about HN user karma or the ability to downvote. It's been my experience that people here have many interests,…

One "philosophical difference" that you need to know about is that comments like these aren't allowed here:

> I know I'll get napalmed for saying this

> And if you downvote this, tell me why, otherwise I'll just assume you are with those that want to exploit me and others.

Please reread the HN guidelines, particularly the last two: https://news.ycombinator.com/newsguidelines.html. If you're going to comment here, please follow them.

The "why is this on HN" genre is also pretty lame.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#97

Post by rrradical »

winteriscoming wrote: post #39

The apparent typo is odd, IMO. I don't know the language in which that program is written, but looking at that snippet, "Transfer" takes 3 arguments whereas the "transfer" function takes 2 arguments. Isn't there any code review involved when this makes into the codebase. Assuming there was some code review and the reviewer just missed it (which is very much possible), a basic unit test case would have easily caught t…

Test cases...code review... How about type checking??

The idea of writing financial software without taking every available precaution to verify correctness is insane to me.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#98

Post by dang »

draw_down wrote: post #36
TazeTSchnitzel wrote: post #7

Earlier quoted context omitted.

> I know I'll get napalmed for saying this, but why is this all over HN? Because the DAO's failure is interesting.

And funny!

A number of internet forums have branched off from HN to fill niches that HN doesn't fill. I'm beginning to think that somebody needs to fork a forum for Schadenfreude. We don't want comments like this here.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#99

Post by willtim »

pron wrote: post #82
willtim wrote: post #74

Earlier quoted context omitted.

Of course most of the money has been funding tools for imperative languages as that is the status quo. But this does not prove that there is little overlap with FP. Research FP languages like Coq have enabled INRIA to build a fully verified C compiler (Compcert), can your tools accomplish this? As far as Europe is concerned, FP does appear to be the future of formal verification.

> Research FP languages like Coq have enabled INRIA to build a fully verified C compiler (Compcert), can your tools accomplish this? First of all, end-to-end verification is something very unique. CompCert is a great accomplishment, but it is only a medium-sized program, it required a world-expert to write, and even then it tool a lot of effort and still he skimped on the termination proofs. Imperative tools, OTOH, a…

I mentioned Lexifi, a contract language, which is based on OCaml and is not imperative. I restricted my argument to Europe as we appear to be less commercially influenced (e.g. MIT teach freshmen Python, Oxford teach Haskell). Predicting the future is always subjective. I offered only my opinion.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#100

Post by tinco »

dang wrote: post #87
tinco wrote: post #37

In addition to this the language is not explicit enough. Even standard Haskell wouldn't be safe enough for a program that manages $250MM directly without safe guards. In addition to typesafety, it would have to be both explicitly typed at the lowest possible granularity and annotated with pre and post conditions. Not only did this code allow a bunch of tokens be transferred without compensation, it left the whole acc…

> It's nice that Vitalik Buterin is a genius, but it shows that this guy is only 22 and dropped out of university because anyone with a degree in computer science knows about this stuff Personal attacks, which this crosses into, are not ok on Hacker News. Please edit such stuff out of your comments here. We detached this subthread from https://news.ycombinator.com/item?id=11928562 and marked it off-topic.

Hi Dang, my apologies, I can no longer edit the comment, please feel free to snip that paragraph out.

I guess I felt the need to accuse someone as I felt frustrated. News like this really smears not only cryptocurrencies but software engineering in general. A single typo cost these people $50M is what they claim, but the reality is that the whole system was recklessly engineered. I guess I'm also saddened that so much money was put behind something that was so clearly recklessly engineered.

Would it been a crazy idea just to invest a million or two of the $250M to pay a Formal Methods team at any university in the world to give the language a quick do-over?

Post reply on HN