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

611–620 of 629 posts

Re: Critical Update on DAO Vulnerability

#611

Post by fmap »

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…

If there are ever more compelling use cases for smart contracts this will create a market for smart contract validation or development.

Interactive theorem proving is already at the level that verifying something like the DAO (a few hundred lines of code!) isn't too complicated. By the time smart contracts become relevant we'll probably have all the tools in place to make this an industry instead of a research project.

Re: Critical Update on DAO Vulnerability

#612

Post by Alexx »

Chris2048 wrote: post #503
Alexx wrote: post #414

Earlier quoted context omitted.

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…

I agree with your analysis there.

But my point was the patent trolling exists because the law is unfavourable. Not because there is a system of mediation in place. If the patent system should be abolished or not doesn't really relate to how inconsistencies in contracts are handled, as far as I can see?

Re: Critical Update on DAO Vulnerability

#613

Post by nialo »

JulianMorrison wrote: post #399
grandalf wrote: post #387

Earlier quoted context omitted.

That depends on whether you think of a contract as an interface or as an implementation. A contract should present an interface that includes a declaration of its behavior. The declared behavior should be well defined, and if a bug in the implementation is discovered, the contract should be updatable to fix the bug. There could even be futures expressing the probability that a contract will be found to have a bug. Th…

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/

Note that this probably means that designing contracts of this sort of "friendly AI complete" in some sense, and therefore not a good thing to be betting on in the short term.

Re: Critical Update on DAO Vulnerability

#615

Post by rabidferret »

vkou wrote: post #517
genmon wrote: post #495

Earlier quoted context omitted.

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?

For an insurance policy like that, they wouldn't offer any policy without auditing the device, including the code.

Re: Critical Update on DAO Vulnerability

#616

Post by rphlx »

street wrote: post #419
sznurek wrote: post #298

Earlier quoted context omitted.

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), an…

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.

Re: Critical Update on DAO Vulnerability

#617

Post by rphlx »

SkyMarshal wrote: post #510
infodroid wrote: post #318

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.

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

> ~23,000 people who blindly jumped on the hypetrain

I haven't touched ETH or the DAO personally, but it is unfair to label every investment in them irrational. Over the past 5 years cryptocurrencies have provided multiple opportunities to convert, say, $10k into $100k or even $1M within a year or two; once your networth exceeds a certain amount, risking 1-2% of it on an opportunity like that is arguably wise - i.e. would be worth repeating - even if it does fail spectacularly.

It is certainly true that as long as that reasoning delivers 10-100x+ returns to some of the people some of the time, a giant fount of speculative money will continue to moisten a lot of scammers, con artists, and insufficiently-careful SW developers though.

Re: Critical Update on DAO Vulnerability

#618

Post by kovek »

I do not understand Ethereum well, but it seems like bigger contracts (with 10$ million worth of value) could be built on top of smaller ones which have been proven (with time) to be correct and not contain mistakes.

We all know that smaller pieces of code can be more easily reviewed and understand. I think that this applies for simpler contracts with smaller value. If a contract has been running for a while without being exploited, then it means that it is pretty solid, and others can build on top of that contract.

It is an interesting dynamic, because there is an incentive to exploit bad contracts, and the contracts that have ran a long amount of time and and that have not been exploited yet are thus trusted to be unexploitable (because no-one exploited them)

If that is how it works, it means that Ethereum will eventually because a fail-proof system. However, one should not mistakenly create contracts from the ground up or using untrusted sub-contracts. The ones who do so will see their contract exploited and everyone will learn from that mistake.

Edit: Seems like Vitalik Buterin asking people to get that patch if they agree for the Ethereum ecosystem to move in that direction is just creating opportunity for fragmentation in the community. It would make more sense to let that "exploit" become a lesson instead of trying to work around this non-issue.

Post reply on HN