Commenting on your second thought: I hoped that people behind DAO (and Ethereum?) will stick to the terms they themselves proposed but it seems they will push hard for forking the chain (see: Ethereum blog).
The DAO was officially introduced by slock.it with "the code of the contract is the absolute truth, any other description is just a guideline", which was hailed as a new miracle by the investors, but now that it doesn't mean mountains of gold the founding principles are suddenly not important anymore, it seems.
The "hacker" simply used the DAO as it was meant to be used (i.e. according to the smart contract code), and deserves the funds. If there is a hard fork, I hope he sues slock.it for controlling the DAO, and for stealing the funds he is owed according to their own terms ("The contract is king").
Whenever they're about to lose, those with the power to do so usually change the rules to ensure they win. Cryptocurrency developers are rarely an exception to that.
Actually, the Bitcoin devs deserve a huge amount of credit for not attempting to "improve" the block reward or total supply during their multi-year bleed down from $1200->$200.
This is a smart response. The insurance company could also review the contract code in order to provide cover -- this would give investors extra confidence.
Suppose that I want to make a medical device, and I want to get liability insurance for when a bug in its code administers a lethal dose of radiation to a patient.
Is there any extant insurance company that would want to review my code in exchange for a lower premium?
If not, why would one be willing to do this for a flash-in-the-pan cryptocurrency, but not a useful, real-world device?
It might also be a question of survival. If $36 million+ is drained from the DAO itself unintentionally at such an early stage, can they continue, and how confident can anyone be that their implementation will be successful if the reference implementation itself is not?
If the DAO is not ready for survival now, then no amount of protecting it will make it ready for survival. What will make the DAO survive is code that only contains bugs that are too difficult to find relative to the value of finding them.
I have a (maybe naive) question: why is the person draining ETH from DAO called "attacker"?
I seems to me that the idea behind smart contracts was to have unambiguous description of what are participants agreeing to. The "attacker" is doing precisely this - I had not heard of any bug in Ethereum implementation that is used, only "bug" in DAO's smart contract. So he is allowed to do this, by contract definition.
Isn't the whole idea of that kind of contracts worthless if people are still rolling back effects of it when "it does not what it was meant to do"?
Obviously you're right, that's tautological! The "attacker" didn't do more than what the system allowed her to do.
People have expectations about what the DAO is and isn't. I'd guess that very few people bothered to read the source code of the contract, let alone look for vulnerabilities. So you have a group of people who have agreed on an informal contract (we pool money, votes are weighted by the sum I've put…) but it turns out that the implementation is not correct w.r.t the informal specification. That's called a software bug and abusing a bug to your own profit makes you an attacker in my book, just as much that using a flash 0-day to drop a rootkit makes you an attacker.
People should have been more careful, but hey, I'm not sure I would have.
The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code.
Doesn't it state that, by definition, that DAO contract is bug-free, so it cannot be exploited? This is exactly what separates DAO case from flash-0-day-rootkit case.
> The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code.
Nice. So if the community ultimately succeeds in preventing the "attacker" from withdrawing his funds, which he acquired in perfect accordance with the DAO code, which is the entirety of the agreement, could he publicly bring suit for violation of contract?
I think he could, but he would be bringing a lawsuit against a decentralized community with no leader. Also, the community still has to accept the fork, if no one does (or very few), he keeps the money. At least that's how it works from my understanding.
It's not a bug by definition of what contracts are. A contract can't have a bug because the implementation IS the specification. That is the whole point of the system. Even the DAO website says so itself. The code itself has the ultimate say:
> Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supercede or modify the express terms of The DAO’s code set forth on the blockchain; to the extent you believe there to be any conflict or discrepancy between the descriptions offered here and the functionality of The DAO’s code at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413, The DAO’s code controls and sets forth all terms of The DAO Creation.
Nobody should have entered this contract if they disagree with the above. Yet now, suddenly most people who are a part of it seem to disagree with it!
What you call an informal contract could also be seen as an incorrect interpretation of a contract.
If you're not willing to call that simply an incorrect interpretation, you end up with two systems - software and people that push the blockchain forward - that interpret contracts differently. You also give precedence to the latter, which will lose the ability to effectively enforce its interpretation the more distributed the system becomes.
Ultimately you have to choose between having one true interpretation of contracts defined by software or being unable to enforce contracts as interpreted by a non-deterministic system.
Choose the latter and not just is there no advantage over real world systems, it's worse at enforcement.
Totally agree. Which interpretation is correct is a decision for the Ethereum community to make (or whoever is in charge, I don't know muck about the governance).
From the article:
> The development community is proposing a soft fork, (with NO ROLLBACK; no transactions or blocks will be “reversed”) […] preventing the ether from being withdrawn by the attacker […]. This will later be followed up by a hard fork which will give token holders the ability to recover their ether.
> I have a (maybe naive) question: why is the person draining ETH from DAO called "attacker"?
George Soros wasn't (afaik) breaking any law or contract when he drained a billion dollars from the Bank of England in 1992. I think most people in the UK would be OK with describing that as an attack.
A better analogy is probably Thaksin Shinawatra, where the rules are very much still up in the air, and where depending who has sway in Thailand, he can expect vastly different treatment.
"George Soros wasn't (afaik) breaking any law or contract when he drained a billion dollars from the Bank of England in 1992."
I also like this analogy. I am also reminded of the Hunt Brothers and their (successful) attempt at cornering the silver market which was then thwarted by a rules change by COMEX[1]:
"But on January 7, 1980, in response to the Hunts' accumulation, the exchange rules regarding leverage were changed, when COMEX adopted "Silver Rule 7" placing heavy restrictions on the purchase of commodities on margin. The Hunt brothers had borrowed heavily to finance their purchases, and, as the price began to fall again, dropping over 50% in just four days, they were unable to meet their obligations, causing panic in the markets."
> I have a (maybe naive) question: why is the person draining ETH from DAO called "attacker"?
It's just a philosophical distinction. Suppose someone who had never built a software program in his life, successfully got a patent for "online marketplace for smartphone apps", and then went and successfully sued random weak-looking people for uploading their apps to the google play store.
Obviously he's abusing the system, and obviously he's a parasite preying on the weak with zero moral justification, in a way that threatens the very foundation of the tech industry... But what he's doing is not illegal; he's just exploiting a flaw.
Is he an attacker?
/shrug
Depends on how you define things, but the context makes the meaning clear in this case, I think.
I understand what you're saying and don't necessarily disagree, particularly as I don't know enough about the subject to form a strong opinion. I would intuit that one might argue the contract was in error if there's a clear indication of intent.
Most software does not constitute a contract. If I run an internet connected computer I don't enter into an agreement with anyone on the internet to use my machine even if its OS has security holes enabling this. The DAO was supposed to be a contract specifying and enforcing in a formal and automatic way what the participants can do.
The DAO's 'terms and conditions' were the contract code itself. During the crowd sale, it was often said that 'investors' need to look at the code because that is the only binding agreement. I guess it turns out that's a lie too.
I expect the attacker either found a contract allowing them to short ether, or made some similar arrangement. Unless it's an attack on tech itself for personal reasons, someone's getting a lot of real money today...
> During the crowd sale, it was often said that 'investors' need to look at the code because that is the only binding agreement. I guess it turns out that's a lie too.
No, it turns out that that's completely true, and that's the problem.
And as such, the contract would include clauses to protect against that. If the contract did not, one of the parties likely can take advantage as they wish.
It is the same with Ethereum. If the DAO 'contract' does not include the terms, the 'lawyer' who wrote it just didn't do a very good job and it is open to taking advantage.
I would recommend "Purely Functional Data Structures" by Chris Okasaki. It's not only for functional programmers - there is also a bunch of structures useful in imperative languages.
I was learning Haskell for last six months (part of my undergraduate studies).
It was (and is!) fun and challenging but I had hard time seeing any measurable profits from learning what are and how to use functors, monads etc.
Until recently when I was writing asynchronous communication framework in Python and I was searching for simple solution to sequence actions in this heavily callback-based environment.
Now everything looks so simple... (I am looking at you, monads!)
The bad part is that many people do not know what I am talking about when I try to describe them the design ;)
I had the exact same experience! A light went off when I figured out how to elegantly sequence asynchronous calls in Scala, and it was then that I realized I was using Monads to do so.
However, I am curious if python's solution looks ugly (since they don't seem to have a 'do' or 'for' expression that Haskell and Scala have respectively)?
I did the same thing in Ruby [1], but it does indeed look uglier than the equivalent Haskell/Scala because of the lack of language support for monadic syntax.
The benefit of realising the monadic behaviour of asynchronous sequencing (which I call "Deferrable#bind!") was that if you had a bunch of nested callbacks, the monad associativity law [2] meant you could replace them with a simple linear sequence of chained bind! calls:
fetch().bind! do |a|
process(a)
end.bind! do |b|
process(b)
end.bind! do |c|
# ...
end
instead of
fetch().callback do |a|
process(a).callback do |b|
process(b).callback do |c|
# ...
end
end
end
I find the former a lot more readable, partly because the "end" keywords don't all pile up at the end, and especially if you try and do error handling (in the nested case the error handling ends up in reverse order!).
I'm guessing you can't really do a 1:1, although maybe the OP can clarify.
They do stuff like this in jQuery, so I can't imagine it's all that difficult in Python.
My initial thought would be to write something analogous to Maybe. You can't pattern match in Python, which is a shame, but you could make it so that foo.bar().baz().quux() will return MaybeResult, which everything involved in the transaction inherits from. MaybeResult might have a "success" variable on it indicating whether it ought to be treated as Nothing. Otherwise, check "result."
This is naive but it gets you a little bit closer to fault-tolerant chaining of interdependent methods. Not as nice as Haskell, obvs. :)
I actually had a very similar revelation in JavaScript. Using Haskell-style arrows to abstract over things like events and CPS functions is really great for that sort of code.
The real beauty of these concepts is that they are not tied to just one logical thing. They're applicable to callbacks and networking, but then they translate effortlessly to handling errors or early termination or non-determinism.
The article missed one important scene from the video - the last one.
Maybe mind control stuff is too far reaching but consider another possibilities: for example censorship. If we would have only one news and data stream all the time in front of us, then you will be literally not able to see and hear censored things.
One can imagine that the contact lenses could remove some object from the vision in real time. Frightening.
Isn't most mass media fairly uniform anyways? I remember hearing criticism that the Rwandan massacre was overlooked for quite a while because most airtime / view attention was dedicated to the OJ Simpson trial.
