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

451–460 of 629 posts

Re: Critical Update on DAO Vulnerability

#451

Post by [deleted] »

semi-extrinsic wrote: post #388
infodroid wrote: post #369

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…

Not to mention: you can use the mere claim of yourself knowing a bug in a smart contract to force the other side to do as you say. If it's sufficiently hard to check for bugs, the other party might accept the cost of doing as you say as cheaper than the cost of checking for bugs again. This was a plot mechanism in some SciFi story I read a few years back. Edit: one of the in-universe early Revelation Space books.

[deleted]

Re: Critical Update on DAO Vulnerability

#452

Post by alvarosm »

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…

Hopefully this will make the idiot "investors" realize what a piece of crap Ethereum (and anything related) is.

Re: Critical Update on DAO Vulnerability

#453

Post by lallysingh »

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…

Formal proofs. These are reasonable to do with modern proving systems, and contracts with formal proofs would be a reasonable output for a specialist in this area, equivalent to a lawyer for regular contracts.

Re: Critical Update on DAO Vulnerability

#454

Post by heroprotagonist »

sznurek wrote: post #298
ar0 wrote: post #280

Earlier quoted context omitted.

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…

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

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?

Re: Critical Update on DAO Vulnerability

#455

Post by Eliezer »

grandalf wrote: post #409
JulianMorrison wrote: post #399

Earlier quoted context omitted.

What you're trying to solve is something very similar to the recursive self improvement problem that MIRI[1] and friends are trying to solve in the sphere of "friendly" artificial intelligence. If something rewrites its own source code, how can you assert invariants that can be relied upon? So going and looking over there at what they've come up with may be fruitful. [1] https://intelligence.org/

Very interesting! Looking at the papers and going to read them. Any specific papers you'd recommend?

"Tiling agents" would be the most arguably relevant. Provably correct agents that approve the construction of other probably correct agents obeying similar invariants.

Re: Critical Update on DAO Vulnerability

#456

Post by dragonwriter »

joosters wrote: post #222
sznurek wrote: post #220

Earlier quoted context omitted.

I am not sure. I believe that in many cases similar activity would illegal or at least forbidden by Terms and Conditions. I the DAO case I am not aware of any regulations or laws that the "attacker" has broken.

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.

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

Re: Critical Update on DAO Vulnerability

#457

Post by vijayboyapati »

Because smart contracts are (often) contractual obligations on real world things, they only hold as much power as the apparatus of coercion (usually the State) will allow them to hold. That is, you must trust the political authority first and foremost before you trust the contract. This is very different to bitcoin, which operates purely in the digital realm, where you can trust the ownership of the btc without requiring trust of the political authority. So bitcoin solves a trust problem and this makes the less efficient distributed architecture worthwhile (it would be much cheaper and far faster to operate a digital currency in a centralized way). But if you have to trust the political authority for digital contracts on physical goods, what is the point of the extra cost? I'm dubious there is any real benefit.

Re: Critical Update on DAO Vulnerability

#458

Post by mikeash »

programmarchy wrote: post #418
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…

Keep in mind Ethereum is less than a year old, the DAO is even younger. It's still new, risky, and fraught with problems that need to be solved. If you're not familiar with anarcho-capitalist theory, there's a concept called a DRO -- dispute resolution organization [1] -- that can perform arbitration functions in a decentralized manner, i.e. without a monopoly on judicial services like the state. In the future, as th…

What's crazy to me about the whole thing isn't the bug in the DAO nor the fact that it's being taken advantage of. As you say, it's all very early stuff, and there's no surprise that it hasn't been fully worked out yet.

What does surprise me is that people poured the equivalent of tens of millions of dollars into this new, unproven thing. To me, this says that while Ethereum itself may be technologically fine, the community is completely bonkers.

Re: Critical Update on DAO Vulnerability

#460

Post by benmmurphy »

jabgrabdthrow wrote: post #52
nneonneo wrote: post #30

The provided link is just a page showing a bunch of transactions. For someone like me, who is not so intimate with the Ethereum terminology in use (but who is still interested in the DAO, as an observer), could someone provide a layman's explanation of what's going on? Somewhat more specifically, I'm wondering the following: - At a high level, what does this attack actually consist of? - How does ethereum "go missing…

It's a reentry bug - native ETH always calls the recipient contract's code on transfer, which can call back into the current function. If you manage native ETH do accounting in the wrong order, you can "withdraw" multiple times. It doesn't "go missing", presumably the hacker will drain it into Bitcoin via any anonymous exchange accounts they have. Everyone loses big time (except the attacker if they manage to launder…

i'm surprised they don't have inbuilt support for some kind of async transfer primitive. so instead of doing:

address.call.value(amount) and the call being synchronous

you do:

address.call.queue_value(amount) and then at the end of your contract execution it runs the asynchronous calls that have been queued

a lot of the DAO calls (all of them??) to external addresses don't need the result so having an asynchronous transfer primitive would have just solved the problem.

these external callbacks are very dangerous. for example you have function _entry_ call function _logic_ and everything is ok. then someone decides to change function _logic_ to perform an external callback and this breaks the behaviour of function _entry_. when you have this non-local side effects from changes you will create security bugs very easily.

Post reply on HN