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

Chasing the DAO Attacker’s Wake – A second exploit

pdaian.com

Post reply on HN
Print view View original

161–170 of 180 posts

Re: Chasing the DAO Attacker’s Wake – A second exploit

#161

Post by amscanne »

Inthenameofmine wrote: post #68
AJ007 wrote: post #20

Nearly a year ago I made the comment -- "Who are these people[1] and what credentials do they have to build and run a cryptocurrency platform?" [1] https://angel.co/ethereum-1 Today, not a single cryptographer, mathematician, or anyone with software security experience is listed on the Ethereum Foundation member list[2]. I am not attacking any individuals by themselves, but as a group this says a lot. For the record,…

Generally speaking the longer someone has been in a specific field, the lower the probability of them thinking of a new method or agreeing with new things. This is a general pattern across the board with anything ews, startups, projects, etc. As somebody working with a lot os startups, having somebody with 30 years of a specific core competency on the founding team is a huge red flag.

Experience is a red flag? That's ageist, and absurd.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#162

Post by jsprogrammer »

homogeneous wrote: post #159
jsprogrammer wrote: post #158

Earlier quoted context omitted.

Can you link to such an implementation?

I'm not really sure what you're asking for. If you're looking for a system capable of accepting payment without an attendant there are many. Here is just one example: http://bw-2e2c4bf7ceaa4712a72dd5ee136dc9a8-bwcore.s3.amazona... If this is not the type of device you're talking about please be more specific.

I was thinking of a system that would let you place a deposit immediately before rental (imagine a rental car in a public lot) and then automatically receive your deposit back when you are done with the car (which was possibly even left in a different lot). I'm thinking the car would use its sensor system to detect if any damage might have occurred and if not, it could trigger the return of a deposit as soon as the vehicle is locked.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#163

Post by rspeer »

mtgx wrote: post #32
HoopleHead wrote: post #27

Every article I see on etherium mentions the DAO. Not one of them explains what it means. Gotta love unexplained acronyms!

It means "Decentralized Autonomous Organization". It's usually used as a common term ("I'm creating a DAO"), but these guys called theirs "The DAO". This attacker exploited "The DAO".

When you say it's "usually used as a common term", that sounds like wishful thinking. It seems you want to take the term back and distance it from The DAO.

But new efforts like this won't call themselves "a DAO" anymore than a new airship would be called "a hindenburg".

Re: Chasing the DAO Attacker’s Wake – A second exploit

#164

Post by splintercell »

chc wrote: post #147
happyslobro wrote: post #136

Earlier quoted context omitted.

This looks like an ideal use case for a Haskel based DSL. We need good static analysis capabilities, and we have to carefully manage side effects.

I'm not sure Haskell's type system is sophisticated enough to be relied on to prevent the kinds of problems The DAO ran into. As I understand it, one of the bugs boils down to recursive calls between two side-effecting functions, which seems like it would probably be just as possible in a parallel-universe Ethereum based on Haskell.

Check ou this paper

http://publications.lib.chalmers.se/records/fulltext/234939/...

Re: Chasing the DAO Attacker’s Wake – A second exploit

#165

Post by aminok »

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.

Natural languages like English imply much more through context, and trade precision for succinctness. This is less true for legalese but still the case. Computer programs need to be explicitly defined and precise because there is no intelligent interpretation.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#166

Post by refulgentis »

TazeTSchnitzel wrote: post #151
refulgentis wrote: post #13

What if the DAO invested in short-selling Ethereum? 🤔🤑

How did you manage to post emoji? I thought HN stripped those (somewhat overzealously…)

Why I used them: I was a little punch-drunk waking up, and the DAO stuff the last couple days has been a great representation of the worst basic instincts we share. I was surprised to see an informal snarky response stay positively scored. I was even more surprised to see that the emoji weren't stripped.

As for the question you actually asked, how did I? Emoji keyboard from iOS 10b1 on an iPhone 6s Plus in Safari.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#167

Post by reddytowns »

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

  Yes,
    but,
      English
        is 
          not 
            commonly
            written

      with
        conventional 
        programming
        whitespace and indentation  
          practices.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#168

Post by tremon »

heliumcraft wrote: post #88
stcredzero wrote: post #71

Earlier quoted context omitted.

It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked. But if you're setting up a situation where server after server is constantly compromised because of hard to discern reasons, then yes, that is a bad idea. Having an internet is something as obviously good as electrical wiring and highway bridges. Having a badly implemented internet is as obviously bad as fault…

Essentially this is the equivalent of a dev mistakely using an eval in the wrong place in a nodejs code. But all these articles are making it sound like the Ethereum team created the DAO and this issues affect Ethrereum as whole, which just isn't true.

The way I see it (continuing the simile): if you're writing something as critical as monetary transactions, everywhere is the wrong place to use eval in nodejs code. And when you're writing a dedicated language for monetary transactions, including eval in your API is just as wrong. The last part is why this issue affects all of ETH.

Solidify is a new language, specifically designed for Ethereum. If the response to contract issues like this is "but that's a known failure mode, don't do that", then that signals a problem with the language, not just the contract code.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#169

Post by jude- »

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…

> this problem can be completely avoided if every method has no more than one external call and always puts it last.

Actually, it's a bit more nuanced than that. If you have methods that make external calls--even if it's the last thing they do--you still have to ensure that all your externally-callable methods do not share state with the methods that make external calls. Restricting where and how often you do your external calls isn't sufficient, since that last external call at the end of your method can turn around and call other methods in your contract (which can alter the contract's state, if you're not careful).

EDIT: clarification

Re: Chasing the DAO Attacker’s Wake – A second exploit

#170

Post by DennisP »

reddytowns wrote: post #167
sandworm101 wrote: post #130

Earlier quoted context omitted.

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

Yes, but, English is not commonly written with conventional programming whitespace and indentation practices.

Just for fun I took one of my longest contracts, removed all the line breaks and added word wrap, and it came to a page and a half.
Post reply on HN