Live data from Hacker News

Critical Update on DAO Vulnerability

blog.ethereum.org

551–560 of 629 posts

Re: Critical Update on DAO Vulnerability

#551
The DAO is written by consultants specializing in Ethereum contracts. They have core developers on their team. They are good, but one mistake is all it takes. (And their business idea to sell a "DAO framework" is probably going to be hard after this.)

The bug that was exploited here has been public for a week before someone decided to try it in practice. There was time to dispense back everyone's ether, had they taken it seriously. But taking security seriously requires an almost superhuman distance to your work.

The Ethereum developers is actively debating whether to put in logic to replay the blockchain in order to give back everyone's ether. While that's probably a good idea, it also means the company behind Ethereum can reverse any contract. That puts them in a difficult situation, as any smart contract platform will have dissatisfied parties at all times. (In comparison, none of the Bitcoin thefts have been reversed, and it's not clear they could have been as development is much less tightly knit.)

It's the most exciting thing since the fall of MtGox. The money at stake is comparable (the DAO is about a fourth of what MtGox was in perceived value).

Re: Critical Update on DAO Vulnerability

#552
post #294

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…

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

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

[1] https://en.wikipedia.org/wiki/Silver_Thursday

Re: Critical Update on DAO Vulnerability

#553

Earlier quoted context omitted.

This is FUD, broadly speaking. The devs have put out a patch for miners which allows them to decide whether or not they wish to fork over these transactions. Centralization is not required for this decision, instead, distributed consensus. The counterpoint to your statements is simply that consumers need safety with their money. It is no badge of honor to let unsophisticated technical people lose money for some extre…

> This is FUD, broadly speaking. The devs have put out a patch for miners which allows them to decide whether or not they wish to fork over these transactions. Centralization is not required for this decision, instead, distributed consensus. With all respect Peter, this is not FUD and OP is raising a valid concern. Yes, the miners vote on the patch - but given the infant state of the ecosystem and the large loss incu…

>so it would appear that there is little leeway in the choice involved.

I think we agree on this. The reality is that an active choice will still have to be made by a consensus group, though. It's not a matter of something being forced down the throats of a majority by an oligarchy, it's utilizing the existing consensus mechanism.

I think OP should be well warned here as to what is binding with smart contracts, for sure. This isn't any different than risk calculations in Bitcoin, though -- early days advice was to wait six blocks for transactions over $20, because the cost of subverting the network was very low. This is part of the give and take of mining and distributed consensus with current technologies.

Re: Critical Update on DAO Vulnerability

#554
Well, their language is disappointing. They allow programs to ignore function return values, a misfeature inherited from C which has no place in a contracts language.

Then there's the possibility of forcing early program termination via stack overflows.[1] Having to protect against that inside each program is just silly. The contract engine should have been designed so that if a contract program crashes, anything it did is rolled back.

[1] http://hackingdistributed.com/2016/06/16/scanning-live-ether...

Re: Critical Update on DAO Vulnerability

#555
post #406

Earlier quoted context omitted.

At this stage yes. That's why I don't hold ether as being solid enough yet to be a store of value, aside from the fact that it's being inflated at ~25% pa. Needs to go through these teething problems now while that is still the case.

Why would that be different at later stages? Bitcoin grew more centralized with time, not decentralized: The miners with the most powerful equipment also have the most ability to become even more powerful. Why is that different for Ethereum?

It's not that simple. In the end it's what users actually use that matters. Mining on a fork that sees no use would be suicidal. So miners need to follow users, or their investment is for nothing. And users tend to follow developers, at least until there is a contentious fork.

So while there is no clear single party that makes decisions, active developers have the most say.

Re: Critical Update on DAO Vulnerability

#556

Earlier quoted context omitted.

Even if we agree that Ethereum is still in its early stages we have to ask whether this response is setting a good or bad precedent going forward. Will the project leadership offer a soft- and/or hard-fork every time a poorly-implemented smart contract is exploited in a manner that is not intended by the contract creators? If every smart contract is going to be "guaranteed" in this way, then this introduces significa…

In this particular case the contract holds 15% of all ether. The fork won't be enacted unless a majority of the community agrees to run its code. That's not likely to happen except in extreme cases, like this one.

Is 15% really that extreme? This is a game; nothing of real value in the world is being created or destroyed (that wasn't already during mining). I personally hope the ethereum community decides to play this game out and not bail out the DAO. It's way too early in the social experiment to change the rules.

Re: Critical Update on DAO Vulnerability

#557

Earlier quoted context omitted.

In this particular case the contract holds 15% of all ether. The fork won't be enacted unless a majority of the community agrees to run its code. That's not likely to happen except in extreme cases, like this one.

In other words, this contract is too big to fail?

Perhaps, but:

a) It is being bailed out by referendum, not mandate. Everyone gets a vote, if you don't want to install the patch, don't do it.

b) The funds to bail it out are those stolen by the attacker. Nobody is asking people without DAO tokens to suddenly contribute their ether to restoring the DAO or take debt.

Re: Critical Update on DAO Vulnerability

#558
post #309
post #291

Earlier quoted context omitted.

I don't know much about Ethereum, but why aren't the contracts declarative? Surely, it would be much easier to see the logic behind the contract and avoid the impossible task of a bug free turing complete language.

The Turing-completeness of the language is the whole point of Ethereum. That's what differentiates it from other (Bitcoin-like) crypto currencies. It allows anyone to build arbitrary business logic--an exchange, a venture capital firm, a game--that is run directly by the participants in the blockchain.

In retrospect, a declarative language might have been a better choice. There's a tendency in open-source projects to make things Turing-complete because it's too hard to agree on what the declarative primitives ought to be. (Hence JavaScript.) This is not what you want in contracts for substantial amounts of money. It's passing the buck to the users.

Re: Critical Update on DAO Vulnerability

#559
post #539
post #507

Earlier quoted context omitted.

Not sure where you're saying Gödel's incompleteness theorems come in, but I agree that DAO is a game of Nomic. Now... the ability to hard-fork is kind of in the rules as well. So it's a Nomic with a complicated endgame. Some guy just won the Nomic, but now he's finding that not only do you want to win, you want to win subtly , or else a majority can vote to undo your win. But anyone who still thinks DAO is an investm…

"Not sure where you're saying Gödel's incompleteness theorems come in, but I agree that DAO is a game of Nomic." I know what he means - he's suggesting that you can't ever get a bulletproof or watertight set of rules or guidelines for a system because ... blah blah ... Gödel's incompleteness theorem. This is a very tempting idea and I myself have given it a lot of thought over the years. The problem is, Gödel's incom…

Uh, I'm at least 70% confident that Gödel's incompleteness theorem applies to sufficiently strong systems of integer arithmetic, and extensions to those, and doesn't need real numbers.

That being said, saying it can't be bulletproof or watertight is too vague.

There is both a first and a second Gödel's incompleteness theorem.

The first shows that a system T which can do arithmetic has some statements that it can express, and which are 'true' , but which cannot be proven to be true by T.

The second shows that a system T which can do arithmetic cannot show that it is self consistent, unless it is not self consistent.

Neither of these seem to be a problem for smart contracts.

It is possible for a system to be self consistent. The smart contract or the system that the smart contract uses does not need to prove itself to be self consistent, so the second theorem is not a problem.

If there is some mathematical statement that can be expressed by the system that the smart contracts use, which the system cannot prove whether it is true or false, this is also not a problem. Which, Ethereum doesn't even have a proof checking thing built into it yet, so I don't see how this would be applicable.

I think that you are probably over-applying Gödel's incompleteness theorems.

Also, I don't think its so much complexity in the "wow these laws are complicated" sense, so much as "strength" in the "how many things can be talked about / shown to be true" sense.

You /might/ be able to do some weird program/proof analogy there, but I really don't think that applying it to law (by a law/program analogy) would really show all that much.

I would think that the law can be understood as being sort of like a function (these inputs result in these outputs), and a function can be both be complicated and total. The law doesn't really do much with formal proofs, as it is now anyway.

Keep in mind that there is also a Gödel's COMPLETENESS theorem.

Re: Critical Update on DAO Vulnerability

#560

Earlier quoted context omitted.

I always wondered why there was such a rush to launch the DAO. As opposed to what Ethereum itself did: develop a proof of concept for over a year, then release a beta version and provide bounties for security bugs, all the while collaborating with testers and security researchers to stress the software.

TheDAO effectively turned into a massive bug bounty, a pot up for grabs.

I am curious if a huge DAO-like organization could avoid being a target solely by keeping very of its wealth liquid at any moment... i.e. what would have happened if 99.99% of the DAO's eth were loaned out... would the hacker have bothered? (assuming it wasn't an inside job)
Post reply on HN