Chasing the DAO Attacker’s Wake – A second exploit

Re:Chasing the DAO Attacker’s Wake – A second exploit by wyager on Tuesday June 21, 2016 @01:28PM (#11947519)

Patchwork solutions won't cut it. "Solidity" is inherently unsuited for the task of safe and correct contract design.

[ Parent | on HN ]

Re:Chasing the DAO Attacker’s Wake – A second exploit by happyslobro on Tuesday June 21, 2016 @03:11PM (#11948535)

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.

[ Parent | on HN ]

Re:Chasing the DAO Attacker’s Wake – A second exploit by chc on Tuesday June 21, 2016 @04:27PM (#11949141)

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.

[ Parent | on HN ]

Re:Chasing the DAO Attacker’s Wake – A second exploit by splintercell on Tuesday June 21, 2016 @11:02PM (#11951288)

Check ou this paper

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

[ Parent | on HN ]

Re:Chasing the DAO Attacker’s Wake – A second exploit by happyslobro on Tuesday June 21, 2016 @06:44PM (#11950057)

Hmm, so the DSL needs to enforce some kind of contract and limit scheme, like that Ada dialect that the aerospace guys occasionally bring up. I bet they have decades of research that the next DAO project devs should familiarise themselves with.

[ Parent | on HN ]