I’m not sure why anyone ever expected adding an extremely expressive language to money contracts wouldn’t end-up being exploited. It’s hard enough writing correct code when nothing important is on the line.
Didn’t you read Accelerando? All corporations are Python scripts and it’s awesome.
not to mention, people have surely been attempting to exploit natural-language contracts for millenia, so why should we expect coded contracts to be approached any differently?
First of all, I’m not even sure that this qualifies as a hack. To label something as a hack or a bug or unwanted behavior, we need to have a specification of the wanted behavior. We had no such specification for The DAO. There is no independent specification for what The DAO is supposed to implement.
This pretty much nails it. ‘Hack’, ‘bug’, even ‘glitch’ seem to be misused as often as the word ‘literally’. And if words are redefined so carelessly that we lose their original meaning, chances are that their concept will disappear as well. It saddens me when words are being chosen so carelessly.
There’s nothing wrong with eating lettuce, but when it lacks the richness of carefully chosen ingredients, just don’t call it a salad, please.
‘Hacking’ is another one of those frequently abused words, with the added bonus of implying guilt, perpetrator and victim. We all know the cases of politicians and “cellebretties” who e.g. after posting something embarrassing or something their party disagree with, use the lame excuse of “my Twitter account was hacked!” No it wasn’t, and making this claim is as insulting as it is condescending. At the very most, someone made use of a vulnerability. Your vulnerability, not Twitter’s. If someone else did this, it’s not hacking, it’s exploiting. But since we are not as gullible as they had hoped, we all “Occam’s razor” ourselves to the most logical explanation: you done goofed and don’t want to admit it.
Now that I got that weekend rant off my chest (cheekily hoping I can get away with this epistle by calling it that), back to the point at hand.
Had the attacker lost money by mistake, I am sure the devs would have had no difficulty appropriating his funds and saying “this is what happens in the brave new world of programmatic money flows.” When he instead emptied out coins from The DAO, the only consistent response is to call it a job well done.*
Indeed. Job well done: exploit succeeded leaving hacks empty-handed.
Should have used Erlang.
I was thinking of something more like Idris, or a language with a type system encompassing pre and post conditions.
If we are actually entertaining notions of alternative languages, I would have to throw my support behind languages that require totality. Idris has a flag to make it default, so perhaps that would be a start, but I would probably prefer Coq or Agda.
Incidentally, by requiring totality, you also guarantee termination. If you want perpetual execution or something similar (e.g., infinite recursion), you have to explicitly opt-in. Seems like that would be helpful.
Formal verification is great, and I would enthusiastically support an experiment using it for cryptocurrency. Not with my money, mind you. :)
I was being more than a little opaque, but a better implementation language doesn’t solve all problems. Even fairly simple contracts like call options and futures contracts are subject to regret. Two parties sign a contract, the terms are very clear. X will buy Z for $100 from Y. Then the market price changes to $10 and suddenly X starts complaining that they didn’t really want to sign this contract. Or the price goes to $200 and now Y says they’ve changed their mind. There’s no ambiguity (bugs) in such contracts. A formal proof that X will pay $100 for Z isn’t going to solve the problem.
Maybe contracts shouldn’t have recursion. How about BASIC?
But I think arguing for a better declarative language misses the point that there’s no guarantee a bug free contract actually matches my understanding/desire.