Live data from Hacker News

Critical Update on DAO Vulnerability

blog.ethereum.org

501–510 of 629 posts

Re: Critical Update on DAO Vulnerability

#501

Earlier quoted context omitted.

The 'Terms' section on DAO website states: 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…

> 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 with…

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.

Re: Critical Update on DAO Vulnerability

#502
post #311

Earlier quoted context omitted.

No-one can write bug-free code No, we can. We just don't, because it's very expensive, and we lack proper tooling to make it cheaper and/or faster. The flaw as I see it is that ETH jumped the gun, and tried to move to software law enforcement without investing the right amount of time/money in the code. Worthwhile goal (though the desirability and practicality remains debatable), bad execution.

> No, we can. There's no evidence of that, and lots of evidence to the contrary.

You can write a formally verified, simple Hello World program and prove that it adheres to both your design and implementation specifications. You can this all the way down to how the specific processor will run the resulting machine code.

The catch is that this is difficult and the time and cost both scale non-linearly with the complexity of the software. But if you can do it for dead-simple programs running on hardware you understand very well, you can do it for complex software as well. Just be prepared to pay millions of dollars for it.

Re: Critical Update on DAO Vulnerability

#503
post #414

Earlier quoted context omitted.

There are no bugs, there is just the contract, and the intent, and the difference between the two. My point is, the institution of law needs to be trusted, yet patent-trolling exists because the institution has failed to apply fair judgment and common sense such that ridiculous legal structures have prevailed.

A bug is the difference between the intent and the produced document.

I disagree. While the use of the word 'bug' is often stretched (i.e. feature requests being made in the issue tracker), the contracts in this case are not purely the product of a writer - they are also a contract, as in a written, explicit agreement. Calling an unintended consequence a bug may be true from the perceptive of the writer, but not necessarily from the perspective of the second-party, who may have agreed to the written contract, but not the "intent". Hence a document with two parties does not have objective bugs in that sense, unless both parties agree, which is not the case in disputes requiring a judge.

Re: Critical Update on DAO Vulnerability

#504

Earlier quoted context omitted.

> participants can generally see the spirit and intent, and at worst go to a judge who will usually enforce the intent Stuff like patent-trolling (and patents) suggest to me the law isn't so consistently trustworthy as you suggest.

My own skepticism isn't so much stemming from any belief that the current legal systems are particularly great as it is from the learned reflex to be wary of anyone rewriting a system from scratch. The legal system is complex and messy sometimes because moneyed interests have been keeping a thumb on the scales and sometimes because the world is complex and millions of people have spent hundreds of years patching bugs…

smart contracts are still a good idea, separate from implementation concerns.

I also consider the strictness, and lack of third-party mediation a "pro", not a "con".

Re: Critical Update on DAO Vulnerability

#505

Earlier quoted context omitted.

> Perhaps, but nobody can write a bug-free legal contract either, and no legal system is without bugs. The difference is that when there is an issue with a legal contract you can defer to an arbiter (a judge) and discuss whether that is a bug or a feature as soon as a divergence of interpretation is detected. Hell, even just having a sentient empowered human in the loop is sufficient, with fully automated response sy…

You are describing human judgement or human discretion. It's probably a given that AI will surpass humans in judgement and discretion of many things in the coming years and would be at least as able to avoid reacting to a false-positive as any human. The problem (and the thing you propose as a solution) is deferring to an arbiter. This is not human judgement as much as it is human authority . We conflate the two in m…

> You are describing human judgement or human discretion. It's probably a given that AI will surpass humans in judgement and discretion of many things in the coming years and would be at least as able to avoid reacting to a false-positive as any human.

Maybe, maybe not, either way that's a worthless pie-in-the-sky declaration because those AIs don't exist and I have not seen you declare that smart contracts shouldn't happen before those AIs arise.

> The problem […] is deferring to an arbiter.

You're confused, the problem is the handling of contracts breaking down due to bugs or boundary conditions.

> the thing you propose as a solution is deferring to an arbiter.

It's not "the thing I propose as a solution" it's the solution we currently have, and one which we know works.

> This is not human judgement as much as it is human authority. We conflate the two in meatspace because of the social rank conferred upon such positions.

Authority and social rank have nothing to do with it, only that both parties accept an arbiter and that the arbiter's decision will be the binding resolution of the issue.

Courts are convenient arbiters as they don't require active cooperation between the parties (quite the opposite) and there are long-standing legal frameworks and case laws, they're not the only option.

> The very idea of decentralization is a different authority model than what is typically in human institutions.

That's irrelevant to the issue at hand.

> In meatspace, a judge must be chosen, elected/appointed, confirmed, etc., and when that judge needs to be replaced we take an entirely different (largely unknown) judge and do a full-scale migration to that new judge's "firmware".

So what?

> With smart contracts, we can divide the execution into many smaller smart-contracts, each with a specific domain of expertise. This makes versioning, incremental improvement, and extreme transparency possible.

You're just masturbating about with "smart contracts" bullshit, you still haven't provided for the handling of contracts breaking down, which is what concerns us here.

Re: Critical Update on DAO Vulnerability

#506

"The "hacker" simply used the DAO as it was meant to be used ... and deserves the funds." Exactly. DAO is CoreWar meets Nomic. https://en.wikipedia.org/wiki/Core_War https://en.wikipedia.org/wiki/Nomic Designers of rulesets (laws, board games, markets, control systems) ignoring Gödel's incompleteness theorems should themselves be ignored. Just like we ignore inventors of perpetual motion machines who ignore the laws…

How is the incompleteness theorem relevant?

Re: Critical Update on DAO Vulnerability

#507

"The "hacker" simply used the DAO as it was meant to be used ... and deserves the funds." Exactly. DAO is CoreWar meets Nomic. https://en.wikipedia.org/wiki/Core_War https://en.wikipedia.org/wiki/Nomic Designers of rulesets (laws, board games, markets, control systems) ignoring Gödel's incompleteness theorems should themselves be ignored. Just like we ignore inventors of perpetual motion machines who ignore the laws…

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 investment vehicle is missing the fact that it's a high-stakes game, and cleverer people than them are going to win it.

Re: Critical Update on DAO Vulnerability

#508
Am I misreading this? The suggested solution is hard code an account hash into the source of Ethereum? If that's the case, how can that be taken seriously? It sounds like Ethereum should just start over entirely. The experiment part I failed.

Re: Critical Update on DAO Vulnerability

#509
post #431

Earlier quoted context omitted.

> No, we can. We just don't, because it's very expensive, and we lack proper tooling to make it cheaper and/or faster. Eh, it depends on how amenable your standards for correctness are to formalization. Also when it comes to security, where clearly bugs tend to hurt a lot more, we're almost always at the mercy of "unproven" (in the formal sense) algorithms. Don't get me started on quantum computing's effects. Reasoni…

The Ethereum virtual machine isn't concurrent even though the network is. The model is a relatively simple serial sequence of operations, state machine style.

The Ethereum VM is only a small issue, the contracts running on it are the actual problem. DAO isn't falling to an ethereum bug.

Re: Critical Update on DAO Vulnerability

#510
post #255

Earlier quoted context omitted.

I see a different problem here: Ethereum and the DAO were not in a mature state to handle this amount of money. For example, there is a limited support for upgrading contracts in Ethereum and the DAO was not reviewed enough to handle hundreds of million dollars. Also, there are methods to make the software ultra secure using formal models.

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.

>I always wondered why there was such a rush to launch the DAO.

So Slock.it could raise money, obviously. A common complaint right around when Slock.it launched the DAO was that Slock.it planned to offer the first funding proposal on it but only provided a brief 2-week period for review and debate before the voting started. It had the appearance of an attempt at railroading the crowdfunding process for a quick payoff.

Fortunately cooler heads uncovered the problems and spoke out, putting the brakes on. Now it's a big learning experience for the ~23,000 people who blindly jumped on the hypetrain and put money into a flawed investment vehicle. You'd think the first 7 years of Bitcoin would have taught people a lesson that this technology is risky, but dollar signs in the eyes tend to obscure hindsight I guess.

Post reply on HN