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

Re: Deconstructing the DAO Attack: A Brief Code Tour

#31

Post by jacquesm » Sat, Jun 18, 2016, 2:06 PM UTC

DrJokepu wrote: post #28

jacquesm wrote: post #10

Earlier quoted context omitted.

> Why are people obsessed with cryptocurrencies? Because they are interesting in a theoretical way and because real world implementations are even more interesting, they show us what the future might look like. > 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? That's not the intent. > Since we'…

> That remains to be seen. Isn't this a somewhat meaningless statement? Is it possible to prove that "no matter what system you create to transfer goods, resources, services or value representing those, it will be exploited"? Is it possible to prove the contrary (that there is or could be such a system)? It will never be seen because we will never know for sure one way or the other. Best we can do is to make educated…

Let's take banking as an analogy: is it perfect? No, it definitely isn't. But it is 'good enough' to power worldwide commerce.

So until these systems reach reliability parity with 'ordinary' banking we'll see reduced trust. But once a system gets launched that has staying power and that appears to have made the right decisions in the founding phase you can expect more and more commerce to ride on them.

When more commerce is involved the 'bounty' on finding a flaw increases and so any system that carries a substantial amount of commerce and that keeps on standing can be presumed audited to that level.

So it really remains to be seen, which group comes up with a system solid enough to carry a substantial fraction of the worlds commerce. Bitcoin is interesting because even after a couple of years it is still standing, which all by itself is impressive.

Will we ever know for sure? I suspect we will not because this is akin to proving a negative, just like you can never be 100% sure that you've found the last bug in a system. But at some point the premium will be so high that failure to exploit the system should give good confidence that all avenues for exploitation have been exhausted and that even if the system still contains flaws those flaws may not be exploitable. It's an asymptotic curve.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#32

Post by willtim » Sat, Jun 18, 2016, 2:07 PM UTC

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'.

While personally I would prefer a functional approach, I take your point that a much more restrictive imperative setting would also be considerably better.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#33

Post by draw_down » Sat, Jun 18, 2016, 2:16 PM UTC

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.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#34

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

Glad I never touched alts. My bitcoin are safe and increasing

Re: Deconstructing the DAO Attack: A Brief Code Tour

#35

Post by kolinko » Sat, Jun 18, 2016, 2:20 PM UTC

altern8tif wrote: post #14

So all this hoo-ha is really just because of a capitalised "T"? If the code were fixed, is the DAO model still valid in the real world? (I'm a cryptocurrency noob... Some of technical stuff just went over my head)

The real question is whether smart contracts can ever be safe enough so that they have real world applications.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#36

Post by draw_down » Sat, Jun 18, 2016, 2:24 PM UTC

TazeTSchnitzel wrote: post #7

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 know I'll get napalmed for saying this, but why is this all over HN? Because the DAO's failure is interesting.

And funny!

Re: Deconstructing the DAO Attack: A Brief Code Tour

#37

Post by tinco » Sat, Jun 18, 2016, 2:29 PM UTC

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 accounting system in a corrupted state! One that could have easily been detected and verified at any point.

This line:

    ```
        Transfer(msg.sender, 0, balances[msg.sender]);
    ```

Should have looked like this:

    ```
        // postcondition: balances[msg.sender] == 0
        Transfer(msg.sender, 0, balances[msg.sender]) :: Action;

    // Compiler result:
    // # Error 1: line XX expected type Action but instead got type Transfer
    // # Error 2: line XX violates postcondition, expected balances[msg.sender] == 0, got balances[msg.sender] != 0
    ```

And the whole function 'splitDao' should have a type annotation that completely captures the possible actions it might encompass, and pre- and postconditions that at the very least constrain the result of the function to not corrupt the accounting of the DAO (i.e. it should still have as many tokens as it believes it has).

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. He should have known the contract language should have had typechecked side effect and he should have known proper pre- postconditions would have been the least he should have done.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#38

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

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.

Re: Deconstructing the DAO Attack: A Brief Code Tour

#39

Post by winteriscoming » Sat, Jun 18, 2016, 2:35 PM UTC

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 this bug, isn't it? After all, the test case would have checked for the balance etc... after execution of these functions. Aren't there any test cases around this?

Re: Deconstructing the DAO Attack: A Brief Code Tour

#40

Post by eudox » Sat, Jun 18, 2016, 2:36 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.

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