Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical Update on DAO Vulnerability

blog.ethereum.org

Post reply on HN
Print view View original

281–290 of 629 posts

Re: Critical Update on DAO Vulnerability

#281

Post by cmdrfred »

drinchev wrote: post #260
cmdrfred wrote: post #249

Earlier quoted context omitted.

I agree, for now. What I argue is that just like nobody can write bug free code, nobody can write bug free contracts as well. I think this might have a good use case down the road once all the bugs are worked out. That said, it's not ready for prime time yet.

Indeed, but you have bug-safety law around the world which incorporates something like : "If there is a typo, error, fraud, crime etc. a contract is considered invalid or the part of the contract that is flawed" With software bugs you have something similar : > NO WARRANTY. THE SOFTWARE IS PROVIDED TO YOU “AS IS” AND “WITH ALL FAULTS.”

Who decides what a typo is?

"Oh, that contact for 1000 dollars is really 10 dollars because they 'missed' a decimal place. You still have to uphold your part though."

Corruption of judges can be a problem in that space and that is in part what this is attempting to solve. A lofty goal, maybe even impossible, but certainly worth the time to try.

Re: Critical Update on DAO Vulnerability

#282

Post by abstractbeliefs »

imtringued wrote: post #265
runn1ng wrote: post #236

Earlier quoted context omitted.

Well, she doesn't, they will block the attacker outright by a centralized decree. What's the better proof that decentralized solutions work than blacklisting accounts and making ad-hoc forks for each attack.

What if the attacker made their move before it could be blocked?

The DAO code that the stolen ETH is held in doesn't allow spending for 27 days, by which time the Ethereum developers hope to have 51% of node power on the fork that blocks transactions involving this address.

Re: Critical Update on DAO Vulnerability

#283

Post by viraptor »

joosters wrote: post #254
mcherm wrote: post #231

Earlier quoted context omitted.

> but they didn't halt trading until they were asked to, so clearly it wasn't totally in their interests? Not at all. This is a classic "coordination problem". It is advantageous for many participants in the overall system to take an action, but only if the other participants are ALSO taking the action. In such a case, a widely followed and popular leader is one possible coordinating mechanism. And it does not give t…

a widely followed and popular leader is one possible coordinating mechanism. That's the exact opposite of decentralized. Are we going to have to redefine the word?

I don't agree. Centralised control would mean one person can change anything. Decentralised doesn't mean that nobody can propose a solution - only that others have to agree on it before it goes live.

How do you imagine decentralised decisions happening otherwise? Everyone choosing their own solution without ever talking to each other and seeing what is most popular?

Re: Critical Update on DAO Vulnerability

#284

Post by lmm »

Udo wrote: post #262

As an outsider, this is stunning to me: why isn't there a contract revokation mechanism? Considering these things are programmable, it could be something as simple as a killswitch hash sitting in a lawyer's safe somewhere, right?

The whole point of the exercise is to not have it under human control.

Re: Critical Update on DAO Vulnerability

#285

Post by vintermann »

walrus01 wrote: post #29

It's almost as if a cryptocurrency system used by the grey market and black market sections of the internet contained actual blackhats. What a surprise. Much as I hate to link to reddit, for effective and biting criticism of cryptocurrencies: http://reddit.com/r/buttcoin

This wasn't the impression I got of Ethereum. Nor am I terribly shocked at their talk of a hard fork. They always seemed more "pragmatic" about these things than typical bitcoin fans, more of a "if a majority of the participants are OK with it, what's the problem?" attitude. Which is IMO more realistic.

The DAO, though, that always seemed slightly fishy to me. "A company for carrying out an undertaking of great advantage, but nobody to know what it is right now".

Buttcoin in my experience has been less about insightful criticism and more about ... well, the kind of criticism the name suggests.

Re: Critical Update on DAO Vulnerability

#286

Post by unknown_apostle »

imglorp wrote: post #214

This is what concerns me about contract programming. With human contract law, if there's a minor typo or loophole, participants can generally see the spirit and intent, and at worst go to a judge who will usually enforce the intent. But with software contracts, only the characters matter and there's no intent anywhere: either you get paid or you don't. ETH is advising, "Contract authors should ... be very careful abo…

Another way to say the same: there is no slack. Errors can be sudden and complete.

Compare with "old fashioned" contract law or e.g. national currencies or gold. The errors there (theft, counterfeit and fraud) tend to impact only one or a few transactions. It's all more localized/

In case of broader failure of old fashioned money (e.g. national currencies being destroyed through inflation): at least this is a very slow process that is usually being telegraphed years in advance.

Re: Critical Update on DAO Vulnerability

#287

Post by ThomPete »

joosters wrote: post #26

Just remember, when the developers inevitably appear with suggestions about how to stop the hack, roll back the blockchain, or come up with other schemes to block the hackers, they are showing everyone that all the talk of blockchains being decentralised, or being beyond the control of governments or other powers... is a complete lie. If this hack can be stopped, then it demonstrates that the currency can be manipula…

It's a size issue not a security issue or put another way the insecurity is the small size.

Once it gets bigger the security goes up as events like this affect the currency less and less.

Re: Critical Update on DAO Vulnerability

#288

Post by lumberjack »

imglorp wrote: post #214

This is what concerns me about contract programming. With human contract law, if there's a minor typo or loophole, participants can generally see the spirit and intent, and at worst go to a judge who will usually enforce the intent. But with software contracts, only the characters matter and there's no intent anywhere: either you get paid or you don't. ETH is advising, "Contract authors should ... be very careful abo…

>This is what concerns me about contract programming.

It is really the whole cryptographic ambition for trust less systems that is possibly problematic.

I'm trying to be open minded. I'll concede that maybe they are will be proven right with time, but maybe not.

Re: Critical Update on DAO Vulnerability

#289

Post by forgetsusername »

icebraining wrote: post #114
mpeg wrote: post #101

Earlier quoted context omitted.

Apparently all that talk of decentralisation goes out the window when you're losing money. Ha

Actually, I'd say the fact that he has to publicly ask for exchanges to stop the trades, and can't simply press a button or send out an order, shows the decentralization. Decentralization doesn't prevent coordination.

>and can't simply press a button or send out an order

And the governmental powers-that-be can press a button and prevent citizens from exchanging cash?

Re: Critical Update on DAO Vulnerability

#290

Post by pron »

ar0 wrote: post #280
infodroid wrote: post #266

Earlier quoted context omitted.

Unlike traditional contracts, the idea was that smart contracts were going to eliminate the need for enforcement or dispute resolution. So that law is enshrined in code. But this incident has set a precedent, at least within Ethereum, that the project leadership will intervene to enforce the spirit of a smart contract. So what now are the benefits of Ethereum smart contracts over the traditional legal system? The way…

Agreed. If this soft and hard fork idea really goes through, it seems that now you are in fact getting the worst of both worlds: For your contract, you have to write code that apparently is very hard to get right and bug-free[1], while at the same time you are at the whim of a "community" -- whose decisions (sorry, "suggestions") can apparently be announced by one guy in a blog post -- not to deem what you are doing…

> might this not be an opportunity to sue the developers implementing this fork in a real-world court?

That would make for a very interesting trial, where a very rigid ideology would be put to the test.

Post reply on HN