Deconstructing the DAO Attack: A Brief Code Tour • Hacker News Board

Re: Deconstructing the DAO Attack: A Brief Code Tour

#41

Post by ethbro » Sat, Jun 18, 2016, 2:37 PM UTC

revelation wrote: post #3

jacquesm wrote: post #2

Whoever thought it was a good idea to have case sensitive function names where the names are allowed to be identical but not identical in function? Major fuck-up there. That should have never passed the concept stage, nor the review stage. Function names should describe what a function does.

What a shitshow. These people don't need "advanced static analysis tools" [1], they need a big old bag of clue. 1: Developers, cryptographers and computer scientists should note that any high-level tools (including IDEs, formal verification, debuggers, symbolic execution) that make it easy to write safe smart contracts on Ethereum are prime candidates for DevGrants, Blockchain Labs grants and String’s autonomous fina…

OpenSSL had some code cruft too, and god knows that didn't stop it from being deployed in production. People use code because it works, not code that's perfect.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#42

Post by ghamrick » Sat, Jun 18, 2016, 2:37 PM UTC

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 don't participate in virtual currencies because I am not smart enough to understand all the nuances, or at least I don't take the time to try and understand them. Plus, I don't have money to throw away. However I find the discussions about the DAO fascinating because of the intersection of technology, law, ethics, morality and government.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#43

Post by tmalsburg2 » Sat, Jun 18, 2016, 2:38 PM UTC

eudox wrote: post #40

tmalsburg2 wrote: post #38

Earlier quoted context omitted.

One solution might be to design a safe language that compiles to the the language used in Ethereum. Not sure if possible within the given constraints.

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.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#44

Post by harmegido » Sat, Jun 18, 2016, 2:41 PM UTC

I'm curious, are there no tests for the code running this? It seems like some of these bugs would be caught with them (especially the typo). And it seems like insanity to not have them.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#45

Post by krapp » Sat, Jun 18, 2016, 2:43 PM UTC

tmalsburg2 wrote: post #38

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…

One solution might be to design a safe language that compiles to the the language used in Ethereum. Not sure if possible within the given constraints.

Wouldn't it be better to just rewrite everything in that safe language and abandon whatever Ethereum is written in?

Re: Deconstructing the DAO Attack: A Brief Code Tour

#46

Post by krisives » Sat, Jun 18, 2016, 2:46 PM UTC

draw_down wrote: post #33

jacquesm wrote: post #2

Whoever thought it was a good idea to have case sensitive function names where the names are allowed to be identical but not identical in function? Major fuck-up there. That should have never passed the concept stage, nor the review stage. Function names should describe what a function does.

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.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#47

Post by tmalsburg2 » Sat, Jun 18, 2016, 2:51 PM UTC

krapp wrote: post #45

tmalsburg2 wrote: post #38

Earlier quoted context omitted.

One solution might be to design a safe language that compiles to the the language used in Ethereum. Not sure if possible within the given constraints.

Wouldn't it be better to just rewrite everything in that safe language and abandon whatever Ethereum is written in?

Sure, but many people are so deeply invested in Etherum that I doubt that it's going to happen. But perhaps there will be a competing system.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#48

Post by niftich » Sat, Jun 18, 2016, 2:58 PM UTC

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 Hanlon's razor to apply but given the amount of money involved, I am not entirely convinced.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#49

Post by fabled_giraffe » Sat, Jun 18, 2016, 3:02 PM UTC

tinco wrote: post #29

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 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, and debates of we should be exploring certain avenues and why we obsess over things are just as valid as any other.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#50

Post by pron » Sat, Jun 18, 2016, 3:07 PM UTC

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 think you are placing far too much emphasis on language, especially as so far there's little evidence that some programming approaches yield less logical errors than others. I often see a similar sentiment expressed by people who are familiar with functional programming but unfamiliar with software verification, and may be unaware that nearly all verified software in the industry is written in imperative languages. I know many FP people like to believe that the local guarantees made by their chosen languages end up making their programs more globally correct; it may well be true that some languages make some errors easier to spot for humans (although we have little evidence to suggest that this is indeed the case of FP). However, as far as formal verification is concerned, there is very little overlap between verified software and FP.

Ensuring correctness -- i.e. conformance to a specification -- is, in general, a task that requires effort -- by man and/or machine -- proportional only to the complexity of the algorithm verified (i.e., the number of states reachable by a TM implementing it) and almost not at all to some linguistic properties. That is not to say that languages cannot prevent local errors that may be catastrophic, but the difference between the best of languages and the worst of languages when it comes to verifying spec-compliance is not that big.

> Using a functional programming language would also mean the code is far more amenable to formal methods and static verification

That is not true. If anything, imperative languages have better formal verification tools than functional ones. And besides, for global program "correctness" properties, the choice of a language more or less amenable to formal reasoning may make a difference that is surprisingly small.