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

51–60 of 167 posts

Re: Deconstructing the DAO Attack: A Brief Code Tour

#51

Post by winteriscoming »

niftich wrote: post #48
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 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 the master branch:

https://github.com/TheDAO/DAO-1.0/blob/master/DAO.sol#L666

(the other repo) https://github.com/slockit/DAO/blob/develop/DAO.sol#L685

The slockit account repo has a commit which was made 6 days back, with the commit message "Protect against recursive withdrawRewardFor attack" https://github.com/slockit/DAO/commit/f01f3bd8df5e1e222dde62... but it doesn't fix the typo and there aren't any more commit in there after that one.

Does this mean, the upstream repos containing the typo haven't yet been fixed? Or am I just looking at the wrong repos/branches? Or did this typo get known only a few hours back?

Re: Deconstructing the DAO Attack: A Brief Code Tour

#52

Post by johnbender »

willtim wrote: post #4

Modelling financial contracts in an imperative event-driven paradigm just seems like an accident waiting to happen. EDIT: To the downvoters, if you disagree, I would very much like to understand why, please reply with a comment. EDIT2: My position is that it is very difficult to reason about correctness and maintain invariants in a highly imperative setting. IMHO, it would be more desirable to use a declarative, or f…

I would go further.

Given the sums of money involved I think it might also be worthwhile to have a formal semantics and a logic for proving safety properties of these blockchain programs (beyond type safety).

Not every application would require that kind of rigour but if the participation and value of a given currency/contract/program is determined largely by trust then it seems natural to want more serious guarantees.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#53

Post by dangero »

tmalsburg2 wrote: post #43
eudox wrote: post #40

Earlier quoted context omitted.

The problem then becomes ensuring that only code compiled from that language can run.

Just let people use whatever they want. Those who write unsafe contracts will get bitten but that's ok.

Seems like this option is now invalid since the devs have now shown their unwillingness to let their pet contracts 'get bitten'.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#54

Post by Atwood »

tmalsburg2 wrote: post #43
eudox wrote: post #40

Earlier quoted context omitted.

The problem then becomes ensuring that only code compiled from that language can run.

Just let people use whatever they want. Those who write unsafe contracts will get bitten but that's ok.

ПРЕДУПРЕЖДЕНИЕ! ^objects in mirror are larger than they appear.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#55

Post by Atwood »

fabled_giraffe wrote: post #6

I know I'll get napalmed for saying this, but why is this all over HN? Why are people obsessed with cryptocurrencies? It's bad enough that those with sufficient computing speed/power can already rip off the stock market; why does the world need another way for people to rip each other off? Since we've determined over history that some people will take advantage of weakness for their own gain, no matter what system yo…

I do not denounce your assertion(s), but, I would like to read how you apply them to Ethereum. To me, the literature seems very much to be attempting to prevent from baking in our (human) duplicitous nature, opting instead for an almost forced virtue. Please suffer a fool and expound/expand for me?

Re: Deconstructing the DAO Attack: A Brief Code Tour

#56

Post by nawitus »

jacquesm wrote: post #24
rahimnathwani wrote: post #18

Earlier quoted context omitted.

I didn't downvote you, but your comment left me scratching my head. You made a statement without any explanation. Care to elaborate why imperative programming is so bad here? Real-world contracts also use imperative style.

This code is very bad, without going into an exhaustive enumeration, case sensitive function names, variables with unclear scope all over the place and so on. That it's imperative code is something that I don't think is damning by itself but all the side-effects (including side effects based on a single bit in the name of a function) really do warrant the 'accident waiting to happen'.

> case sensitive function names

Are you saying that function names should be case-insensitive?

Re: Deconstructing the DAO Attack: A Brief Code Tour

#57

Post by jwr »

willtim wrote: post #4

Modelling financial contracts in an imperative event-driven paradigm just seems like an accident waiting to happen. EDIT: To the downvoters, if you disagree, I would very much like to understand why, please reply with a comment. EDIT2: My position is that it is very difficult to reason about correctness and maintain invariants in a highly imperative setting. IMHO, it would be more desirable to use a declarative, or f…

I partially agree — e.g. yes, declarative specifications would have been better. But having looked at some of the code, it's just poor quality. Bad code, plain and simple.

If you write bad code, you will eventually get bitten. If you use bad code to build a financial institution with great claims, it will also cost you money and reputation.

Bad engineering has consequences.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#58

Post by jacquesm »

nawitus wrote: post #56
jacquesm wrote: post #24

Earlier quoted context omitted.

This code is very bad, without going into an exhaustive enumeration, case sensitive function names, variables with unclear scope all over the place and so on. That it's imperative code is something that I don't think is damning by itself but all the side-effects (including side effects based on a single bit in the name of a function) really do warrant the 'accident waiting to happen'.

> case sensitive function names Are you saying that function names should be case-insensitive?

No, I'm saying that if function names are case-sensitive that you're an idiot if you use that feature to distinguish between two functions otherwise named identically with different (important) side effects. The fact that the parameter set is different implies auto completion by an IDE was probably partially to blame here (if you did it by memory you'd have gotten a wrong parameter count warning).

Some language features you best not exploit if you want to write reliable and bug-free (to whatever extent possible) code.

This is not a typo so much as it is a very poor choice of naming convention.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#59

Post by benjcooley »

krisives wrote: post #46
draw_down wrote: post #33

Earlier quoted context omitted.

The problem is deeper, this idea of contracts enforced by computer code written by humans ( = full of bugs) is a dumb one.

Just because some smart contracts fail doesn't mean they all have to.

The problem is one of trust. Contracts that can either be formally verified, or by nature of the language they are written in are mathematically guaranteed to be free of certain bugs and behaviors can be 'TRUSTED'.

It's a very bad thing to not be able to trust that your money can't be trivially stolen.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#60

Post by wyager »

fabled_giraffe wrote: post #6

I know I'll get napalmed for saying this, but why is this all over HN? Why are people obsessed with cryptocurrencies? It's bad enough that those with sufficient computing speed/power can already rip off the stock market; why does the world need another way for people to rip each other off? Since we've determined over history that some people will take advantage of weakness for their own gain, no matter what system yo…

That is extraordinarily pessimistic and rather short-sighted, to be blunt. The point of cryptosystem-based financial tools is that they're more... raw than the normal financial tools we have access to historically. They work by a much stricter set of rules. This means it's easier to mess up and lose money, but it also means they're more efficient, predictable, and equitable.

The existing financial system is inextricably entwined with our political and legal system. This is both good and bad. Bitcoin, ethereum, etc. are efforts to make financial systems that are independent of politics and central management. In my opinion, Bitcoin has done a much better job, because it's actually reasonably decentralized and they don't change the rules whenever people get their money stolen.

Post reply on HN