Chasing the DAO Attacker’s Wake – A second exploit

Post by tylervigen » Tue, Jun 21, 2016, 6:44 PM UTC

DennisP wrote: post #106

cheeze wrote: post #80

Earlier quoted context omitted.

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous , given what is at stake when a bug is included in a contract. Is there any form of auditing that contracts can go through to not have these pitfalls? I wonder how many of them are still undiscovered...

There's both an active developer community willing to help for free, and professional auditors you can pay. There are also people talking about a NASA-style bugs/best practices database at some central location. People are realizing that this needs to be developed like safety-critical software, not like fast-moving startup websites. But I would say it's not as scary as, say, developing software for aerospace or medic…

Post by DennisP » Tue, Jun 21, 2016, 7:02 PM UTC

sandworm101 wrote: post #130

DennisP wrote: post #106

Earlier quoted context omitted.

There's both an active developer community willing to help for free, and professional auditors you can pay. There are also people talking about a NASA-style bugs/best practices database at some central location. People are realizing that this needs to be developed like safety-critical software, not like fast-moving startup websites. But I would say it's not as scary as, say, developing software for aerospace or medic…

Five pages? I thought these things were meant to be shorter than plain-English contracts. I draft and review contracts daily and five pages is long for basic things (employment, NDAs, IP transfer etc).

Post by happyslobro » Tue, Jun 21, 2016, 7:09 PM UTC

axlee wrote: post #89

DennisP wrote: post #30

As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last. I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them…

If this code style is an absolute requirement for the code not to be exploited, it should be probably be built-in in the language specification itself.

Post by DennisP » Tue, Jun 21, 2016, 7:12 PM UTC

JulianMorrison wrote: post #28

bouk wrote: post #15

Seems like this is what mutexes were invented for

With a mutex, an A -> B -> A call would deadlock if the mutex is the stop-and-wait or spin-and-retry sort. It would have to be a succeed-or-exception mutex, which is not a common design.

Post by sandworm101 » Tue, Jun 21, 2016, 7:23 PM UTC

dragonwriter wrote: post #138

DennisP wrote: post #133

Earlier quoted context omitted.

It's software, not really comparable to an English-language contract. Most software is much bigger than that. Five pages is an outside estimate, for something like a currency exchange. My crowdfunding contract is about two pages, and the vault is one.

> It's software, not really comparable to an English-language contract. If the point is to be an alternative to normal, "dumb" contracts, than that is exactly what it needs to be comparable to.